Approaching Behavior Driven Development (BDD) from a Test Driven Development (TDD) perspective
Over the years doing TDD, I'm getting increasingly concerned about the value my test fixtures are bringing to the table in terms of documenting features and expected behavior.
So far, I followed the typical pattern in TDD of creating
one class (fixture) per object under test: if I have
DirectoryService, I create DirectoryServiceFixture. Inside
the fixture (and for the past couple years now), I've been
pushing teams I work with to stick to a convention where
every test method is prefixed with the word "Should": this
seems to be at least a bit
...