One of the things that really interests me about the Behaviour Driven Development discussion is the effect it has on how you organize your specs. [...]
The reason that clarity is important is that specs serve as documentation for future development. If you want to understand how to use a class, look at the tests. Right?
# Disclaimer - this is also an example, not a recommendation
# -- but closer to a recommendation than the example above!
A stack
- should add pushed item to the top of the stack
- should return the top element on peek
- should not remove the top element on peek
- should return the top element on pop
- should remove the top element on pop
An empty stack
- should be empty
- should complain on peek
- should complain on pop
An almost empty stack (with one element)
- should not be empty
- should not be empty after receiving peek
- should be empty after receiving pop
[...]
[...] The generic "A stack" context describes the normal case for how a stack behaves, while the other contexts deal specifically with how a stack at or near a boundary behaves differently from the normal case. This is a far more clear specification [...]
Previous Topic
