Is TDD Dead?

An interesting read: http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html
A purposely inflammatory post that had the desired effect of bringing out some TDD heavyweight advocates on Twitter including Bob Martin and Martin Fowler....

There are some interesting points to draw from David's Twitter stream:

• He learnt the ins-and-outs of TDD first before moving on (and he learnt a lot from it).
• He says his view of the testing world only applies to Rails apps where tight Web + DB integration/coupling is a design choice.
• He has very opinionated beliefs about how Rails apps should be built including
• Rails apps should remain "small-scale"
• ActiveRecord usage should be carefully maintained
• ... both of which are often not the case in reality.
• Patterns of building/testing Rails apps like Hexagon are overkill if you're building a small Rails app with business logic intended only for web audience - but can be useful if that Rails app is a peer among other interfaces.

My summary:

• Learn TDD inside-out, learn where it fits rather than getting caught up in dogma. 
• Know what type of app you're building
• Then carefully design and architect your application to be testable through careful and appropriate use of unit/integration/system testing
• Ensure your architecture is carefully and purposefully maintained.

I personally use a "Test Oriented Development" approach:

• Exploratory coding should be done as part of a spike - normally on a "spike branch"
• There's often not much point writing up-front tests when you need to try something you've never done before - this can be a form of waste
• Kent Beck (the inventor of TDD) himself doesn't write tests before exploratory code - podcast
• When you've solved the problem, jump back onto master and rewrite the solution this time with testing in mind - carefully plan Unit Tests, Component/Integration Tests, & Acceptance Tests
• If you can't pair commit to master, push to a temporary review branch and submit a pull/merge request to a reviewer

Interesting response: https://www.destroyallsoftware.com/blog/2014/tdd-straw-men-and-rhetoric

And another one from Martin Fowler about self-testing code:  http://martinfowler.com/bliki/SelfTestingCode.html

These kinds of benefits are often talked about with respect toTestDrivenDevelopment (TDD), but it's useful to separate the concepts of TDD and self-testing code. I think of TDD as a particular practice whose benefits include producing self-testing code. It's a great way to do it, and TDD is a technique I'm a big fan of. But you can also produce self-testing code by writing tests after writing code - although you can't consider your work to be done until you have the tests (and they pass). The important point of self-testing code is that you have the tests, not how you got to them.