How much unit testing is a good thing? [closed]

Answer 1

Two suggestions for minimal unit testing that will provide the most "bang for the buck":

Start by profiling your application to find the most commonly used parts - make sure those are unit tested. Keep moving outward to the less commonly used code.

When a bug is fixed, write a unit test that would have detected it.

Answer 2

I always believe in not being extreme. In particular when time and energy are limited. You just can't test it all.

Not every methods/functions need a unit test. The following might not need. (1) The one that is clearly not complex like just get/set, little condition or loop. (2) The one that will be called by other method that have unit tests.

With these two criteria, I think you can cut a lot of those.

Just a thought.

Answer 3

Automated unit testing brings a lot to the table. We've used it on several projects. If someone breaks the build, everyone immediately knows who did it and they fix it. It's also built into the later versions of Visual Studio. Look into

Test Driven Development

It should save you a lot of time and doesn't produce a significant amount of overhead. Hope this helps! If so, mark it.

Answer 4

While it is possible to over test (point of diminishing returns) it's hard to do so. Testing (particularly testing early in the process) saves time. The longer a defect stays in a product the more it costs to fix.

Test early test often and test as completely as is practical!

Answer 5

While unit testing is useful, you should definitely have a system test plan for every release - this should include testing the normal use-cases of your application (for regression) AND the specific feature being worked on in more depth.

Automated system testing is pretty much vital to avoid regressions - unit tests can all pass and your app will still be a crock of dung.

But if you can't do automated system testing for all of your use-cases (most applications have complex use cases, particularly where interacting with 3rd party systems and user interfaces), then you can run manual system testing.

User interfaces create the main problems - most other things can be automated relatively easily. There are heaps of tools to auto-test user interfaces, but they are notoriously brittle, i.e. in every release the auto-tests need to be tweaked just to pass (assuming no new bugs).

Answer 6

Test enough so that you can feel comfortable that a bad refactor will be caught by the tests. Usually, its enough to test logic, and plumbing/wiring code. If you have code that is essentially getter/setters, why test them?

regarding the sales guy's opinion that testing isnt needed - well, if they know so much, why dont they do the bloody coding?