Argument Exceptions should be Unit Tested?

Question

I know this question is pretty similar to others that have been posted before but I would like to discuss this topic in a proper way.

Do you think that the "obvious" exception should be unit tested?

With obvious exception I mean for example exceptions due to null arguments or empty strings or negative numbers in situations where we the business logic of our unit make us obvious that these exceptions will always be thrown at the beginning of our method(s) before any other operation.

In other words I'm speaking of the exceptions that should be thrown after the violation of the simplest part of a class contract.

Thank you for your opinion.

Answer 1

I usually include these tests. Its actually a nice place to start development, because if you are using TDD you can have the simplest test possible to start writing production code, and if you don't use TDD you have a nice passing test :)

Answer 2

Absolutely. You call them "obvious," but there's nothing obvious about remembering to verify pre-conditions. In fact, most of the code I've seen in my career does not take this obvious step to prevent mayhem later on.

While you see this a lot in library code that's written for public consumption, reuse, etc., remembering to put such checks into one's own code often seems to slip by most developers. In a test-driven environment, putting tests for such conditions forces developers to properly validate input parameters on their public methods.

And let's be fair... any chance I get to write another test and see the green bar, I'm happy. :)

Answer 3

Yes, you should unit test even the simplest logic in your getters and setters. If that code changes during refactoring, you want the unit test safety net in place to make sure no mistakes are made. Running the tests is a really quick way to find these mistakes as soon as they're made.

The only time I don't test getters and setters is if they are doing only simple assignment or returning a value.

Answer 4

I'd always also write a test for such "simple, obvious" things mainly because

• An according test for these "obvious" situations is usually written very quickly and therefore I'm nearly faster in quickly writing it rather than thinking about the fact on whether to put a test or not
• A simple test case is better than no test case
• Test for future changes. Having a test makes sure any other dev in my team won't break my code during refactoring/bugfixing etc...