What are the criterion to understand if someone used TDD?

Question

I'm approaching the TDD methodology for software development, reading guides and writing simple applications, because a client of my company wants a software and asked to develop it using TDD methodology.

So I was wondering, besides "trusting" the documentation and reports we'll create, how can one understand and be sure that TDD was followed. I thought that maybe the content of test can be different from the one that would be there if written after coding, but I'm not completely sure.

And even if this was the case, what are the hints I should be searching to understand if the software was developed that way, if I were to look to someone else's project?

Answer 1

Objectively, there is no way to find out if the tests were written test-first or test-after.

But my personal opinion is that someone who is truly experienced with TDD will recognize if code was written test-first or test after. As they produce noticeably different structures and code. Also I have found that writing test-after often causes major edge-cases to not have tests. Even whole areas of code might not be covered by tests as there was stress to continue writing "production" code instead of tests.

Answer 2

You can't prove that a particular methodology was applied to arrive at a particular result.

However, in the specific case of work-for-hire, where the customer owns the resulting IP rights, they could ask for the whole history of development as recorded by your source control tool.

If that history shows that you add a test, then add implementation, then refactor, as separate commits, then it's pretty indicative of TDD being followed. It still isn't proof, as you could construct such a history post-hoc, having developed under some other methodology, but I can't imagine such a ruse being cheap.

Answer 3

I suppose that using TDD will result in a cleaner code and design. While clean design doesn't automatically mean that TDD was used.

I'd analyze such things when assuming TDD was used:

1. A class has more getter functions than is used: to call them from tests to check a state.
2. There's a small amount of High cohesion: such things are difficult to test.
3. Each class has a unique responsibility.