Reputation: 5236
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?
Upvotes: 4
Views: 331
Reputation: 6562
I test most stuff.
Whenever I write tests I also consider tests to be documentation or instructions on how my code should be used, for me and others to read in the future.
I don't test implementation though. I want to be able to change the implementation without changing my tests.
I have used TDD for maybe a year or two so maybe I will mature and stop. So far, though, I'm still learning and think that I don't write enough tests.
Upvotes: 0
Reputation: 17457
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:
Upvotes: 5
Reputation: 7937
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.
Upvotes: 3
Reputation: 18904
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.
Upvotes: 3
Reputation: 61262
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 ;-)
Upvotes: 3