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.
Here's the full interview:
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:
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:
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.
If you have any questions, feel free to keep the #TDDIsEvolving twitter hashtag discussion going on.