How to practice TDD when I constantly need to ditch my current test?

Question

I'm learning and trying TDD recently, and I constantly encounter a situation when I need to ditch my current test because it's too broad. I don't know how to deal with it. To be more specific, let's suppose I have a class User, which contains a method getInfo. To follow TDD, I need to write my test first:

@Test
public void test_get_info() { ... }

Then implement my method:

class User {
    public UserInfo getInfo() { ... }
}

When I'm implementing the method, I suddenly find out that there are two kinds of users, one is Employee, the other is manually-registered user, one test is not enough to cover both. To get info for both kinds of users, I need to create two more classes:

class Employee extends User {
    public UserInfo getInfo() { ... }
}

class RegisteredUser extends User {
    public UserInfo getInfo() { ... }
}

Before implementing it, I have to write two tests one by one for Employee.getInfo and RegisteredUser.getInfo. But suppose when I've finished writing the test for Employee.getInfo and try to implement it, I find out that UserInfo contains user name and user address, both have complicated logic and deserve a separate test case. Thus, before implementing Employee.getInfo, I need to write tests for UserInfoFetcher.getUserName and UserInfoFetcher.getUserAddress...

Have you seen the problem? To pass the first test, I need to write multiple other tests and pass them before the first one. It doesn't seem like TDD, which usually demands one test each time. How do you solve the problem?

Answer 1

I voted to close this question as a duplicate, because I think this case can be solved by applying this answer, but let me explain it a little bit more in-depth by using your specific example.

The problem vanishes by working in smaller steps:

• First make test_get_info pass by a really simplistic implementation of getInfo. For this, test_get_info shouldn't try to test something complicated, only something you can resolve with a few lines of code. The fact you "suddenly find out that there are two kinds of users" should not stop you from implementing getInfo for a simple User up to a point it can be compiled and tested.

• Even when you know you need two types of users, add only a test for Employee.getInfo and make that pass by adding the new Employee class (still using a simplistic implementation, maybe one which reuses and/or overloads User.getInfo). Don't add two tests at a time, like you described it!

• Do the same for RegisteredUser.getInfo.

• Don't forget to refactor in between (the tests will help you to make sure you don't break anything).

• Now you are planning to replace the oversimplistic logic by the real one. As soon as you realize you need this new method UserInfoFetcher.getUserName, write a test for it, then implement it (but don't change any getInfo implementation at that point in time).

• Then add a test test_get_info2 for getInfo which cannot be passed by the simplistic implementation any more. Getting this test pass will require to change getInfo in a way it uses the available getUserName, which is now just a "baby step".

• refactor further, run the tests again...

In reality, you may choose a different order to work here, but I guess you get the idea. If it helps, you can first scetch test_get_info2 before working at getUserName, but leave it deactivated / in comments until you got getUserName ready (which is what the top answer from the dupe suggests).

Answer 2

Personally I mostly write the tests at a higher layer being the API meaning I avoid the implantation detail like this.

The way your tests interact with the code creates a contract that is hard to change later. Given the API is an existing contract that you don't want to change its quite stable. Stub out external services and use an in memory db and they can be reasonably fast, although still relatively slow vs a pure unit test.

I started TDD focusing on unit tests but slowly realised I often missed bugs due to them being higher up or in how the components connected. Writing tests for the higher layers often felt like I was duplicating the setup of the other tests. Any refactor often meant throwing away many tests and writing them from scratch instead.