I'm sad to say it, but it is true. It slows you down. But not everytime, and not for everything. So let's be more specific on the cases where it DOES slow you down noticeably:
- Cowboy or Duct Tape Programming Mode: If you code all day like crazy in a "cowboy" or "duct tape" programming mode, then it WILL slow you down, significantly. In this mode, you're hacking together stuff that works by pure luck, you're only superficially and typically manually "testing" the thing, before calling it "done" and move on. Someone will come after some day when the customer complains about a bug, and figure out what to do. Not your problem though, for sure. For all you care about, you might even have another job by then. Your productivity kicks ass, you're the fastest guy in the team, and can get "complete" features to your boss in record time. Everyone (who hasn't worked with you long enough) thinks you're a genious, 'cause you can get something that works on the first shot. Brilliant!...
Read full article
Over the years I've come to realize that the one-fixture-per-class approach to unit testing just doesn't scale. As the amount of variations in state and interactions increases, that file starts becoming a big soup of "Should" methods that are increasingly difficult to traverse and find later on. Essentially, since every test is doing the first "A" in AAA (Arrange-Act-Assert) too, that means the context is also part of the test method.
You can only make a method so long and remain understandable at a glance: IfRepositoryContainsACustomerAndAddingANewOneWithSameIdButDifferentAliasThenThrowsInvalidArgumentException. So, a while ago at Clarius we started exploring some of the concepts behind BDD (Behavior Driven Development), Context/Specification, etc., while working on an internal project. ...
Read full article