Warning: This article will come off as some serious flamebait. If all you do is take it at face value then I will take a page from Justin's book and probably tell you that you make up part of the collection of people I will be talking about be a jerk. Alas, without further adieu...

Over the past few years there has been a great paradigm shift in developer maturity vis-a-via Test / Behavior Driven Development. This has been great and undoubtedly has helped our industry. Like all good things it has also started a downward spiral of dogmatism and a lemming effect for inexperienced developers. I am going to call these groups "Rcov Alchemists" and "Monkey Testers".

First the Alchemists. Rcov is a great tool, and arguably essential to the development process. That being said it's focus has been a better marketing tool than a development tool for some and is starting to hurt the development process. The reason I am coining this phrase Rcov alchemists is obvious when looking at code written by some more junior level developers that were not taught anything but "The code must be 100% covered". Now this is not the developers fault, so they do what they are told and write tests to make the red turn green. They don't understand or have the panache to defend their case even if they do realize that some of the stuff they are doing may be correct, but some edge case in the tool they are using just doesn't register the code as tested. This can breed bad habits and poor tests just to accomplish what seems to be a great goal. Now most of us know that 100% code coverage doesn't mean jack-sh%t. It really becomes more of a feel good for customers / managers, and a marketing tool. Now I will say that used in that context it's pretty powerful, but as developers we really need to take a step back and make sure that we aren't pushing code coverage for the sake of code coverage. I could go on further about this but for the sake of your attention span and my curiosity as to what you all think I will stop on this one here.

Now the Monkey Testers. If I had a Venn diagram as a visual aid here we would see a large overlap between this group and the aforementioned. I am defining them differently because their behavior creates a different problem. This problem often manifests itself the way of test bloat. This is where the paradigm shift has come to bite us in the ass. We have preached test test test to everyone, but not always backed up the test first part. When you examine the tests closer you will see a very one to one style of testing that tries to be overly exhaustive. Now here is where a lot of people will fight back and that's ok. For me this is testing for the sake of testing and beyond a project's needs. A test needs to cover the specifications / declarations that drive the code that gets written, no more, no less. That is an incredibly loaded statement and may sound like a cop out and just me trying to duck out of what I am complaining about, but take a step back and think about it. The overly exhaustive tests were obviously not part of TDD/BDD practices, and just serve to clutter up the intention of the test itself. A test should be able to communicate to the developer its intent in a clear and precise way. On that note and in spirit of wrapping up the Monkey Tester is also a trait that is not always the fault of the developer and can be helped if we take the time.

I am proposing to those of you out there that have figured out the art of testing not to just preach testing and 100% coverage, but to explain what it is you do to be successful and help some of the newcomers avoid these two problems. Let's take our industry beyond dogmatism and introduce it to real pragmatism and push it to the levels of success that we all know we can.

Let the floodgates open!