2

This question already has an answer here:

Currently we don't do much testing at our company, except some manual checking. We occasionally create some unit tests, integration tests and ui tests, but not on a regular basis. Since a new project is coming up I want to take the opportunity to implement a better way of testing.

Question

Since most of our web applications are actually performing basic crud applications, a lot of tests seem to be trivial. And my question is basically, how do I decide where I draw the line, is there an approach for that. Altought unit testing improves the quality, it comes with a cost (in the form of writing them and maintaining them). To get concrete, here are some examples.

Example

I have a productService with the following method:

public Product GetProduct(int productId)
{
   return database.GetObject<Product>("select * FROM products wh..",productId)
}

Should I create a unit test for this method? Let's say that I would, than I'm just checking if I'm calling the right query and if I'm forwarding the productId parameter correctly to the database layer. This feels already a little bit trivial. But to make it worse, I'm already planning to create an integration test for this method to check if it all works correctly together so this unit test won't add any value. But if I would follow TDD (which is dead, partly because of this reason as I have heard), than I should create that unit test.

Any thoughts?

marked as duplicate by gnat, Community Nov 14 '16 at 5:44

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 2
    Whilst the answers from here are detailed, I don't think your answer is as straightforward. Whilst it would be easy for me to say to prioritise what you choose to add coverage for, it assumes perfect conditions. How will the client react to the time spent on this? Are you billing them for post delivery support / maintenance? Has testing time been allocated in your estimate? etc... – Dan-Cook Nov 13 '16 at 12:04
  • 3
    TDD is not dead... It just doesn't accomplish what you think it does. – Robert Harvey Nov 13 '16 at 15:26
  • 1
    You see how GetProduct method looks like today, but I can see a future beginner in 5-10 years asking to SE: "I have inherited legacy code that has no unit tests and I have been asked to refactor a service that after a little change has caused 25k errors/warnings. What to do now?" – Laiv Nov 13 '16 at 16:32
  • 1
    @Laiv: That question has been answered... Scream until you find someone who can help! – gnasher729 Nov 13 '16 at 20:36
  • @Dan-Cook: well they give me indeed clues, together with your advise it gave me enough to get going :) – Maarten Kieft Nov 14 '16 at 5:48
3

I'm already planning to create an integration test for this method to check if it all works correctly together so this unit test won't add any value.

Your actual goal is to prevent broken software from going into production, isn’t it? Unit testing is just one of many tools to achieve that goal. If your integration test catches the same error as the unit test, then that’s sufficient as far as effectiveness is concerned. No matter how adamant TDD is about testing everything, having that specific unit test will not make you catch any additional errors.

But what about efficiency? When the integration test fails because the GetProduct() method broke, how much time and effort will it take to reach that conclusion from the data the integration test provides? If that number is high then the additional cost of writing and maintaining a “second line of defense” might be worth it.

  • Your answer with the comment of dan-cook (and the answers of the other question) gave me hints I needed. Since your also gave me a concrete answer to the example,i mark yours as answer. Thanks – Maarten Kieft Nov 14 '16 at 5:59

Not the answer you're looking for? Browse other questions tagged or ask your own question.