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 ...