Some Alternative Ways of Reading Context/Specification
I have been playing with BDD conventions for several days and while I am no expert, I genuinely enjoy the way this style forces me to consider design before creating code.
I have tried to catch up on all the BDD purse fights going on out there and I understand that there are passionate differences in the way people prefer to interact with their tests. That said, regardless of what verbiage is being used or I believe what we are really doing is
preparing to test / invoking the SUT / asserting what the SUT should have done
In that spirit, can someone tell me the difference between these 3 base classes used for unit tests?
If there is a big difference there I am not seeing it.
What do the tests themselves look like?
And how about the all important test runner view so that we can see the results of our tests? Can you tell which mental model produced which test?
So that last point is my point. The way you choose to think about your contextual configuration doesn?t need to be a slap fight, it is just how you think about it. I personally like to think in the GWT mental model and even apply it to my system components. So what?
There are some nice things people have come up with to reinforce their favorite mental model. SpecUnit for .NET is full of tasty morsels to be begged, borrowed, or stolen into your own tests.
The important thing, IMO, is that I can use these tests in a report to explain to my mom what my code is doing. And mom doesn?t code.