Test writing strategy advice

Question

So, I'm getting more and more engulfed with test driven development these days and the more code I write while thinking tdd, the more decisions it's seems as though I have to make about the extent of testing that I should write. I would like to set kind of a personal policy as to how much unit testing I should write for my own projects, and was wondering if I get some advice as to how what kind of you approach you all take.

Here an example of a decision that I'm currently facing...

I have three classes...

public class User
{
    public string Username { get; set; }
    public List<Favorite> Favorties { get; set; }
}

public class Favorite
{
    public string Username { get; set; }
    public int rank { get; set; }
}

public class UserManager
{
    public List<Favorite> GetTop5(User user)
    {
        var qry = from fav in user.Favorties.OrderBy(f => f.rank)
                  select fav;

        return qry.Take<Favorite>(5).ToList();
    }
}

I have a data access layer for the User class for which I already have a "GetUser" test setup. As you can see, in my business logic I have a method UserManager.GetTop5() that returns the top 5 favorites for the User that I just pulled out of the db. This method is very simple and currently involves NO external resources or dependencies.

So my question is would you go ahead and write another test for this "GetTop5" function point, even though there's very little chance for failure?

Do you setup a test anyway in case you extend upon the functionality in the future? Or do you think that a test here is excessive?

Answer 1

when doing TDD, I write at least one unit test for each feature.

so, is GetTop5 a feature? if so, it deserves a test. If it's not a feature, then it doesn't need to exist ;-)

Answer 2

Good point with writing the test afterwards! If you first implement the functions and then test them it feels odd. Thats why you should first write the tests and then implement the functions. Moreover this will force you to think about how you want to use your functions. In addition if you first implement whatever you want to implement, you'll find yourself in situations where the code is hard to test anyway. And again the test first approach helps with this, the code will be more testable if you start with implementing the tests before the actual implementation of your functions.

Answer 3

Yes I would write a test for that method as well, in general you should have test for feature you implement. Remember TDD is not just for testing if the method works, you should also test how it handles exceptions, for instance what were to happen if it got a Null as the user object.

When developing using TDD, you are really designing the API other members of your team will have to use, so TDD allows you to write how you'd like the API to be used, that means how it's called but also how errors are handled. For more complex methods you might want to return your own custom exception, to make it clearer what went wrong.

Answer 4

You won't believe this, but here's what Kent Beck had to say, right here on StackOverflow:

"I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don't typically make a kind of mistake (like setting the wrong variables in a constructor), I don't test for it. "

Link: Link: