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:
Writing tests forces me to think what I want to achieve
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.
BDD is getting confused with some of the tooling
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."
A mock returning a mock, you think - stop!
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:
When building APIs, developers are your customer - find out what they want
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."
I've never seen testing teams in another building or another country work well
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'm becoming property test infected
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.