@Machuga
Your code tells a Story. Someone should be able to recognize the flow of data through your objects
Stories are not just told, they are interpreted. Everyone might have a different interpretation
Something that you find clear, your users might find ambiguous
- Arrange - Set up preconditions and input
- Act - on the objects or functions
- Assert - that your assumptions are correct
Behavior Driven Development
Uses more descriptive language. Output is very nice for business
Ruby testing libraries?
- Be Expressive.
- Tests are code too, refactor them
- Respect the cukes
- Cucumber/BHat
- Bad stories are signals
- Plot holes
- Mocking the object under test
- Global state mutations
- Implicit Behavior
- No descriptions
- Creating abstractions that provide no benefit
- No explanation why the environment is in current state
- The world is bland and empty
- Lack of Character Development
- Performing transformations on characters out of Views
- Mocking collaborators without clear reason
- Switching narratives
- Setting expectations on collaborators
- Blurring lines between suites
- Plot holes
- Unit test in isolation
- Try TDD/BDD (2 weeks)
- Feature First (MVP)
- Supports slice plans
- Wastes fewer resources to test an idea
- Feature First (MVP)