Should I write unit test for everything?

Question

I am wondering should I write unit test for everything. There are some classes is very difficult to write unit test. For example, I am writing some program for handling audi

Answer 1

I only write unit tests where I know it saves me time. When I started out unit-testing this was only a small percentage of the classes (those awful ejb's!!). Today I test almost everything and I save total development time on every single thing I do. If there was an efficient way of testing user input through a microphone I'd do it too. But as far as I know, it's not possible in a manner that saves me time.

So i think you should unit test everything that is in your current "test capability". You should try to stretch this capability, but overreaching really sends signals of wrong priorities; In all likelihood there's some other test that deserves your attention more. (Technically I'm test infected but not TDD infected)

The law of diminishing returns applies to unit testing as much as any other testing; your payback on that last 5% is very low and the cost is high.

Answer 2

Other example: If you develop a game engine, you want to test your shadowing and other functions, but you have to confirm it visually - that's nothing a classic UnitTest can decide.

Your Case: As your application becomes more complex it gets painful always to click through your UI to test all your functions.

I would write an "interactive TestSuite", where various dummy dialogs (customized for each test-case) are shown with only the functions you need to test. Once you close the Dialog, you will be prompted if the behaviour was expected. But I am not sure if there are solutions available which could help here.

Answer 3

If you're facing difficulties setting up a particular area of code for testing, it might be worth investigating a mocking framework like jMock, or EasyMock.

Answer 4

Designing tests is an acquired skill - the more you test the better at it you get. Some things appear hard to test but if you think about it for a few minutes you can often find a way.

Tests can be messy - e.g. a java program can launch an interpreter or even a shell such as bash which in turn launches a series of unix filters which you hope will output identical binary files. Don't worry though - the quality of test code does not have to be as high as the code in the finished product.

Answer 5

I tend to write tests as much as I can. Not only to prove that something works, but to make it obvious to someone else when they inevitably break it later.

I've had a method that was 1 line long. In similar places in my app I had written unit tests, but being in a rush I thought that it could not possibly fail. I was wrong, it didn't work :-)

The additional benefit of writing unit tests is not only to test your code, but so that someone who has never seen your code before can read the tests and understand how your code should work given specific scenarios...like a specification.

Answer 6

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.