When should you stop unit testing

Question

I can often identify plenty of areas which are nicely encapsulated and easily unit tested, but I also find that a lot of code where unit testing doesn't really seem to work as well - typically data access and user interface. No matter what unit testing "techniques" I try I tend to find that in these places it's not only a lot of effort to create functioning unit tests, but these tests tend to be very fragile and don't really test very much.

At what point do you stop and decide that the benefits of unit testing isn't worth the cost?

Answer 1

When there isn't time in the project plan for it and time is being spent finding ways of testing rather than working towards the goal of the project.

Answer 2

If you have the access to some live data you can use it to unit test. also u can use data generators and random data. Unit tests only give you some level of confidence that it wont create problems in the future. If you are confident with your testing you can discontinue unit tests

Answer 3

I tend to test only the model and data persistence. testing the model is mandatory. UI (desktop application, webapps, command-line interface, etc) is hard to test, so I write test for it only in rare circustances.

Answer 4

When you can provide better value by doing something else.

Answer 5

I like the title of the question. Apart from that I think it is a dupe of Is there such a thing as excessive unit testing?

Answer 6

I would say when you've gained an acceptable level of confidence. Also, like for my project at work, we are under such tight time requirements that I really have to only test certain parts of code (not all of it) just to give me a good confidence level.

Answer 7

Usually I only test the model and the controller. Unit test are hard to apply for UI, usually i prefer manually test the app.

If creating these test cost more time than manually test everytime you might have a regression, then the test is useless (easy to say, but not to evaluate...).

Answer 8

If you need to cut out testing, cut out integration or end-to-end testing. Misko Hevery at Google explains it really well here.

"Unit Testing gives you more bang for your buck"

is the best quote to come out of his article.

Other than that, when you have decent code coverage and are handling a few edge cases of your code then its a good time to stop unit testing.

Answer 9

As far as data access testing goes have you tried mock tests to simulate responses.

Answer 10

The basic rule of thumb i'd follow is if the effort to build the unit test is more than the effort to repeatedly manually test the feature by human work.

If you look at the Test projects in the Visual Studio Team edition for Testers, there is such an item called a "Manual Test" which is essentially an instruction document to tell a human how to carry out the test and manually pass it. Certain things, like you mention UI testing, or code to workaround obscurely odd or buggy hardware behaviour in the underlying framework or OS or driver, are better verified by human eyes.

Answer 11

If you are using TDD, then you stop unit testing when all the tests in the test list have succeeded.

Otherwise, you stop unit testing when the cost of finding more bugs through unit testing exceeds the cost of finding them through your QA process. and when you've reached an acceptable level of code coverage through the combination of all tests.