The Evolution of TDD

Last week I had the privilege of interviewing Nat Pryce about the past, present and future of TDD, BDD, Mocking, GOOS, tools and practices. Nat and I agree that TDD is not dead - it's evolving, hence the hashtag #TDDIsEvolving.

On TDD and Design

The conversation started with concepts around design. Nat mentioned that "TDD is not just about unit testing it is the mental process of thinking how I am going to show that it's working to myself and to other people" and completed by saying:

On BDD

Nat began this topic with the issue that "BDD is getting confused with some of the tooling. I don't find all of the tooling very useful, but I find the collaborative process useful - you don't have to use cucumber or any other tool to do it." He mentioned he's spent a lot of time refactoring Java code to make it readable, which reminded me of a project where we've created a Java Code DSL to express test behaviour.

On Mocks and 'Is TDD Dead'

As we mentioned before, Nat does not think TDD Is Dead, instead, he believes it's evolving. We spoke about some of the problems raised during the debate being related to the misuse of Mocks. When mocking sometimes "people overdo the isolations" - "A mock returning a mock, you think - stop!". "A class can be composed of other objects that don't have to be exposed and don't necessarily have to be mocked."

On Microservices and APIs

The highlight of the discussion around Microservices and APIs was clearly Consumer-Driven Contracts - "Being able to write a test for somebody else's service and have your test become part of their continuous integration is quite a change and it's been really useful in my experience".

Here are a couple of his recommendations in this area:

• Have each team (consumer) write the tests the way that they want and have them published
• Same idea of having conversations between "stakeholders", in this case, the consumers are the stakeholders

Some examples of tools for this type of test:

• Pact & Pacto
• JSON Schema with plain JUnit

On the Evolution of Roles

I asked what he thought about the fact that "We've moved from a world where developers wouldn't write tests to a place where it's a reality that developers take responsibility and accountability for the tests". Unfortunately he pointed out that "It's still not the reality everywhere".

We've touched on the point of having a separation between developers and the test automation teams and here's what he said: "I've never seen testing teams in another building or another country work well. If a test is not easy to write, change the design. This feedback loop is hard if people who write production code and automated tests are not close to each other."

On The Future - What's next?

One of the trends mentioned by Nat is Property based testing, which, according to him, is "where your test is structured as a predicate that defines a property of some aspect of your system and the test framework generates random inputs", he also mentioned that this is a "great way to find unknown unknowns". I wrapped up by saying that it "sounds like bringing some exploratory intelligence to automated testing". Nat finished by saying that "it's fun to play with".

According to him, the trends are mainly around Consumer-Driven Contracts, Property based testing and Monitor-Driven Development.

I want to thank Nat Pryce for the interview and also want to thank some key people without whom this would not have been possible - Britt Klontz, Heather Malec and Kaifeng Zhang.

If you have any questions, feel free to keep the #TDDIsEvolving twitter hashtag discussion going on.

This post was designed and produced by Kaifeng Zhang