Having dealt with the pain of a large test suite (with way too many integration tests) that has greatly inhibited productivity I’m really on board with what this article is saying.
Of course this is not to say down with TDD and all the great it’s inspired, but people need to get real about testing.
Some of my favorite points:
I’ve always felt that tools created for the sole purpose of measuring test coverage are just silly (get back to coding things real people actually care about). As have I found the verbosity of “Given, When, Then” “BDD” testing to be silly. Integration tests have just bit me in the ass way to many times. They’re slow, unstable, hard to maintain, hard to write, and just don’t reap enough reward for cost when they test the most top level integration of UI which likely gets iterated on all the time.
I tend to favor pragmatism. The TDD culture can sometimes feel like a cult that looks down upon anyone who writes some of their tests after-the-fact and doesn’t praise the almighty 100% code coverage flying spagetti monster.
This term “computer science” can make people feel like there’s always some mathematical answer to programming. That by somehow having a robot scan your code to determine coverage will mean no one will ever have to stay late on a Friday fixing a bug that made it’s way to production. When in practicality, it’s just naive to think there’s some infallible answer to that. We try to avoid production bugs as much as possible, and tests certainly are very necessary for that, but they will find their way in sooner or later. And when that day comes you don’t want to have to wait for your brittle, bloated, hour+ long test suite to finish to push a fix.
I love the internet & DIY
Play their LP online for free, sweet url (dscvry.net) & bad ass music. (big ups to Wes from Syracuse native Ra Ra Riot).
Spots are going up in value in the art market!
From the creator of Spine.js–smart guy.
Even more exciting to hear these guys are trying to create a framework for “Steam for HTML5 games”.
