Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Skeletal Test Suite #11

Open
2 of 3 tasks
digitalextremist opened this issue Jul 20, 2016 · 5 comments
Open
2 of 3 tasks

Skeletal Test Suite #11

digitalextremist opened this issue Jul 20, 2016 · 5 comments
Assignees
Milestone

Comments

@digitalextremist
Copy link
Contributor

digitalextremist commented Jul 20, 2016

Basic foundation for test-suite, focusing to start-with on base objects.

(checklist by benzrf)

  • Enumerate stuff to test.
  • Enumerate testable behavior in each thing.
  • Write tests.
@sarahzrf
Copy link
Contributor

How fleshed-out does this need to be, and which stuff do I need to have tests for, by the end of GSoC? E.g., do I need to write tests for the Piece startup process as a whole? for parsing Designs? for any multi-Piece interactions?

@digitalextremist
Copy link
Contributor Author

Celluloid convention is TDD so there is a tacit expectation that there be tests for everything.

You seemed shocked by this. At the very least, all the tests need to be setup, but kept pending or xit or equivalent. This is an unfortunate compromise.

Ideally, all tests for all objects and all processes would be in the repository before code was originated/migrated. So after the outline of bypassed tests are done, and all the other items on your roadmap, complete as many tests as you can ( and then do more ).

@sarahzrf
Copy link
Contributor

sarahzrf commented Aug 5, 2016

Stuff to test:

  • Color
    • Wrote some tests already
  • Line
    • Wrote some tests already
  • Spool (if we're even keeping Spool around)
    • TODO
  • Frame
    • Provisioning
    • Event publishing
    • Startup and shutdown
  • Logger (module in Internals)
    • Difficult to test because so much stuff calls into it. It's hard to isolate.
  • Figure
    • Face initialization
    • Line initialization
    • Event handling
  • Management
    • Manage
      • Can issue instructions and wait for replies
      • Leader automaton functions correctly
    • Cooperate
      • Executes instructions and replies
      • Follower automaton functions correctly
    • Administrate
      • I'm not personally clear on what this is supposed to do, once implemented.
  • Awareness
    • Notice
      • Reports
    • Announce
      • Heartbeats and presences
  • Vitality
    • Correctly handles an attaching follower
    • Sends out pings
    • Correctly handles a follower dying
    • Utility methods work as expected
  • Logging (shape in Base)
    • Run under an ID other than :logging so that it doesn't get logged to by normal code.
    • Collate
      • Prints logs
    • Document
      • Sends logs
    • Relay
      • Relays logs
  • Calling
    • Answer
      • Answers calls
    • Switch
      • Switches calls
    • Call
      • Places calls
  • Distribution
    • Distribute
      • Distributes (and collects?) tasks
    • Process
      • Pulls tasks
      • Reports results
  • Certain Figure interactions - need to work this out.
    • TODO

Do we need tests for the Sketches from Ef? They don't seem to be core ECell functionality.

@sarahzrf
Copy link
Contributor

@digitalextremist Just how skeletal can I get away with this being?

@sarahzrf sarahzrf modified the milestones: sd, GSoC 2016 Aug 15, 2016
@sarahzrf
Copy link
Contributor

OK, I've added it clauses for each of the behaviors outlined above. How much do i need to fill them in with?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants