When testing for an excluded exception, how much about this exception should I check?

Question

This is consistent with my shallow understanding of best practices for handling exceptions.

If I write unit tests for test cases that throw exceptions, does it matter to me that the correct type of exception has been selected or do I need to check more? In particular:

• If I call a method and expect a NullReferenceException, should I check for this exception and make sure it comes from where do I expect?

• If an exception is thrown, do I need to immediately not care about the state, or is it still true to make statements about the state of the system?

• If I pass nulls to a method and a NullArgumentException is thrown without worrying about which argument it is being called, or has it just been thrown?

At present, I believe that after an exception, all bets are excluded from the point of view of the state of the system, and a deep penetration into the exceptions is bad, because at this moment you begin to check how your method is implemented.

thanks,
Mark

Answer 1

If I write unit tests for test cases that throw exceptions, does it matter to me that the correct type of exception has been selected or do I need to check more?

If you consider the test as something that stimulates the design of your application, you need to check everything that makes sense for the future client of the class.

If I call a method and expect a NullReferenceException, should I check for this exception and make sure it comes from where do I expect?

In tests, you always check whether you get the desired results by a known result. This way you call the method and get an exception. You do not have to care about what and how he was abandoned - you are just fine with the fact that he was abandoned.

If an exception occurs, do I need to not immediately care about the state, or is it still fair to make statements about the state of the system?

It depends on the requirements. If your application / library should work after exception handling and has the correct state - you need to check this.

If I pass nulls to a method and a NullArgumentException is thrown without worrying about which argument it is being called, or has it just been thrown?

Suppose your library is a black box. You are missing something, you are returning something. It does not matter how the results were obtained. No matter what has been done.

UPD

like @eschneider mentioned in the comments, you should also check that the generated exception is of the correct type.

Answer 2

If I call a method and expect a NullReferenceException, should I check for this exception and make sure it comes from where do I expect?

Do you know about your code that you get from this test? If it is - test it. With NRE, it can be enough (and usually) that you know that it has been thrown under certain conditions and that is all about it.

If an exception occurs, do I need to not immediately care about the state, or is it still fair to make statements about the state of the system?

It fully meets your requirements. If the state after an exception needs to be handled in some way, then you should definitely write tests for this.

If I pass nulls to a method and a NullArgumentException is thrown without worrying about which argument it is being called, or has it just been thrown?

Think about your end user. Will he care about which argument raised the exception? Will you take care If your end user is a programmer going through a log file to find a possible reason for the failure, then I can imagine that he will be grateful to you for the information provided. There is always a question: "Is this some kind of value for the user?". If this (and you want to make sure that this value has been provided) - check it.

At present, I believe that after an exception, all bets are excluded from the point of view of the state of the system, and a deep penetration into the exceptions is bad, because at this moment you begin to check how your method is implemented.

The exception indicated in the title means an exceptional situation. Regardless of whether all bets are disabled, it depends only on what your application uses in these exceptional situations. If all bets are disabled, I assume that your application will act the same way (processing it in the easiest way and forgetting about it). However, if your code wants to do something (for example, a magazine, format for the end user, repeat, etc.) with the indicated exception, then checking it is really the right exception, with the right message thrown in some clearly defined point - all of these get value and deserve testing.