If you had two projects with the same specification and only one was developed using TDD how could you tell?

Question

I was asked this question in an interview and it has been bugging me ever since.

You have two projects, both with the same specification but only one of these projects was developed using Test Driven Development. You are given the source for both but with the tests removed from the TDD project. How can you tell which was developed using TDD?

All I was able to muster up was something about the classes being more “broken up” into smaller chunks and having more visible APIs, not my proudest moment. I would be very interested to hear a good answer to this question.

Answer 1

The people in the interview have assumed that someone developing code does not know how to properly abstract out things like separation of concerns, dependency injection, single responsibility, etc. unless they are using TDD. This is a horrible interview question, and you should think nothing less of yourself for not being able to provide a reasonable answer. The only real answer is "you can't".

I've seen much code that has had improper tests written for it, and as such has forced the code into a form that is not conducive to maintenance. I have also seen exceptionally easy to maintain code written without a single test.

Answer 2

Actually, a lot of sacrifices must be made to make code testable. Because of this, code written using TDD tends to look very distinct from non-TDD code:

• Almost every class will have its own interface. This is because, in C#, it's not possible to mock concrete classes. In Java, it is possible, but most of the major mock-object frameworks discourage it anyways.
• Dependency Injection. The cost of Dependency Injection can often outweigh the benefits, so even in non-TDD projects that do use DI, it won't be used everywhere. However, once you call new MyClass() in a method, that method can no longer be tested in isolation from MyClass. Thus, in a TDD project, almost every class will either be injected or have a factory-class injected. Which leads us to...
• Most classes not instantiated at startup will have a separate factory class for the reasons stated above.
• All classes are public. This is because non-public classes can't be accessed (and thus tested) from a separate project. Yes, this defeats the purpose of having access specifiers on classes at all, but thus is the world we live in.
• Much fewer methods are private, because private methods can't be tested. What often happens in TDD-code instead is that we pull the private methods into a separate class, or we make the methods public, but not include them in the interface.
• Modularity. Projects utilizing TDD tend to be more modular, simply because the more modular something is, the easier it tends to be to test.

Answer 3

I would generally say that you're going to have better "seams" for decoupling in the TDD code base. It's not just about being smaller or more "broken up", but rather about being more modular.

A TDD code base often makes me think of Legos in a vague way. That is, you have a bunch of small, independent (with help from interfaces) components that can be assembled or mixed and matched at runtime, largely in whatever fashion you please. Contrast this with a non-TDD code base, where this outcome is much less likely. TDD forces me to have ways to set an object's dependencies, and so I do. Non-TDD allows me to build Iceberg Classes that monolithically hide all decision making about collaborators and object creation.

Edit: In addition, you'll tend to see much less use of static methods and state in TDD code-bases, in my experience.

Answer 4

This seems like an odd question to ask for an interview, but here you go:

The cyclomatic complexity of subroutines follows a power-law distribution. So, if you graph a cumulative histogram of the cyclomatic complexity of the individual subroutines on a log-log scale, you will get a straight line. The magnitude of the slope of the line tells you wether the project was developed using TDD or not: anything above 2 is with TDD, below 2 is without.

Note: nobody knows why that is so. Nobody knows what the slope of the line means. Nobody knows if the slope even means anything. But, AFAIK, nobody has yet been able to find a counterexample. Also, people generally find that code that they are happy with always has a steeper slope than code they are unhappy with. And they find that refactorings which subjectively improve code quality always lead to a steeper slope.

• _{Author interprets this measure as}

  _{A steeper distribution [larger magnitude of the slope] suggests a preference for less complex methods}

Source: Measure for Measure – Keith Braithwaite.

Answer 5

The TDD project makes heavy use of the dependency injection pattern. The non-TDD project uses it sparingly, if at all.

Answer 6

Presumably, any feature implemented to spec in TDD would have a test written for it (first). The TDD project will have a subset of functionality but will implement each feature with simple objective tests correctly.

The idea is that the other project will implement a feature first, then fix bugs found.

The assumption here is that both projects are not yet complete. For the TDD project, not all features have been implemented. For the non-TDD project, not all bugs have been ironed out.

In the interview, this is explained by a hand-wavy explanation that both projects asymptotically approach the ideal project state of feature-complete and bug-free. The TDD project approaches it from the bug-free direction and the non-TDD project approaches it from first hitting the features.

This would quickly be followed with the ol' "Does this rag smell like chloroform to you?" and some sub-conscious (unconscious) hypnosis technique. If you have the flashy-thing from Men In Black, you can use that instead of chloroform.

Edit: after reading the other responses, I think I have a better one:

There's a TDD principle: Write just enough code to pass the test

Look for code above and beyond the spec (i.e. anticipating future expansion of scope), in any method. Similar features like generalizing cases with only one concrete implementation are also signs. TDD shouldn't have such things.

Answer 7

Look at the interfaces in the system

The easiest way to test something is to provide dummy implementations on the things needed that are not under test.

If you have interfaces describing larger chunks of the system then it is a very good indication that those interfaces were used in a test.

Then have a look at the methods in these interfaces describing larger chunks, and evaluate how well thought out they appear to be. It usually shows very clearly if they were written before or after the main code hiding behind the interface. If most or all of them were written before the main code implementing them, then it is a very good indication that TDD was used.

Answer 8

Seems like an unanswerable question. As I see it, the interviewer expected either:

1. A "clever", but concrete answer. Something like, "feature language X is not used in a TDD project because such code cannot be tested."

2. A bunch of vague points about how the TDD project should have less redundant code, easily used APIs, fewer bugs, more modules/classes, in other words things that are not necessarily true, but somehow prove that the candidate "knows" what TDD is (or has read all the hype about it).

In either case the question could have been better phrased. (To clarify, I think TDD is a great idea, and I try to use it when I can, but I'm also perfectly aware that some people can produce amazing code without writing tests.)

Why don't you ask the interviewer what he had in mind, if that's possible?

Answer 9

As evidenced by this article analyzing a study of TDD in relation to code quality, the TDD code will be of worse quality than the non TDD code. Though this study only had 2 groups, one that tests first (TDD) and one that wrote code first, but did use unit tests. So this would only be true if both samples had unit tests.

Answer 10

How can you tell which was developed using TDD?

If it is done properly, then there are no ways to tell which process is used to create an application. Not even if you can take a look into the unit tests.

Of course, if there are no unit tests, or low unit test code coverage, then it's easy :)

Answer 11

Check for excess parenthesis.

There are two ways to try and reduce the bugs in your code. You can test things or you can try to write your code very carefully. A common form of trying to be careful is not trusting the precedence rules of the programming language. Instead, programmers tend to explicitly parenthesize everything to make sure that there are no surprises. In contrast the TDD developer doesn't put in the parenthesis because he trusts that any silly errors he makes will get caught by his tests.

It comes down the question of what the developers trust to deal with bugs. Do they trust in their coding style or in their tests? I think that'll give a very good indication of whether they are TDD or not.

Answer 12

It very largely depends on the code written.

While some languages will show a heavy usage of interfaces in a TDD project, this isn't a very specific criteria that would guarantee you could tell either way. You can develop TDD in non-OO and non-interface-supporting languages also. I found it odd that none of the other answers (at the time I write this) seem to have addressed this, though I suspect that this could be because of the Java tag on the question.

If both projects are well factored, contain no duplication, and can be said to meet all of the requirements, then it really should be impossible to tell which project was specifically TDD. If not, then you might in a very general sense be looking for the program that may contain duplication, and may be more likely to exhibit a number of methods that do more than they strictly should. Even so, the quality of the code will largely come down to the experience of the team members working on it, and just how fussy those developers are about sticking to the SRP and DRY principals.

Answer 13

Are you sure this wasn't intended as a trick question? I could imagine many answers being of the form where someone either rants or raves about how TDD would produce X, Y and Z in the code and thus they would figure it out that way.

Could you come back with a, "Why would you want to know such an answer?" just to see what the main point is of asking such a question. Course an interviewer may reply, "This is just a hypothetical to see how well do you know TDD," or something like that.

Answer 14

I would sum it up something like this. The TDD code will have:

1. Smaller classes and shorter methods
2. Public properties and methods that make sense (in other words, they look like they were created before the code was written, because they were)
3. Lots of dependency injection
4. Objects created using factories and/or factory methods rather than using the "new" keyword
5. Higher use of interfaces (not required, but TDD code will tend to have more interfaces)
6. Fewer calls to static methods