2

As mentioned in this post, Exception vs Assert?, exceptions are used for run-time error conditions, and assertions are used for coding errors.

As far as I know, unit-test is used to verify the functionality of a function. Besides the legal test cases that we know the result already, do we have to write some illegal test cases in unit-test to test if the assertion occurred or the exception has been thrown?

gsamaras
  • 71,951
  • 46
  • 188
  • 305
  • 1
    Depends on the functionality of the function. If it is specified that it must throw an exception on some input you have to test it. If it is specified to produce some behavior on certain inputs and undefined behavior otherwise then you d̶o̶n̶'̶t̶ can't. – nwp Sep 08 '17 at 08:33
  • As `assert` are coding error, you should not be able to "launch" them (and if you can, it would be UB in release anyway). – Jarod42 Sep 08 '17 at 09:04

4 Answers4

1

You could. It would be a good idea to test whether the assertions and/or exceptions occur, when a "bad" scenario happens.

Read more in:


PS: Do you have to? Well, that depends on your project.

gsamaras
  • 71,951
  • 46
  • 188
  • 305
1

Your question cannot be answered in a generic manner.

Perfect unit testing is impossible, even "very good" unit testing is incredibly hard, and is possible only when testing "very good" code. Be careful to not fall into this trap, all depends on your quality requirements.

Do you develop a mission critical system when a failure can cost lives? Go an extra mile and test as much as possible. Any change will have to pass lots of bureaucratic steps anyway. Otherwise adapt to your requirements. One of the main benefits of automated testing is simplified refactoring, when you can change (sometimes significantly) your implementation and still be sure it works to some extend. Too much testing and this gun points at you cos any change will require lots of changes in tests eventually blocking your progress.

No silver bullet as usual

Andriy Tylychko
  • 15,967
  • 6
  • 64
  • 112
0

Ask yourself: Is a exception or assertion code? Why do you write that exceptions and assertions? They have functionality! The should protect your code against e.g. unexpected data coming from "outside". So if you need that kind of protection, you have to check for the functionality of your code.

What happens if you do not check your code: Maybe the range of your check for your exception is wrong and you throw in cases where it was not expected or you do not throw but your execution runs now in undefined behaviour.

My argue is simply that: You write code and exceptions and asserts are code. The code do something useful and so you have to check it. From the logic point of view asserts and exceptions did not differ from if/the/else error handling. And to get a full calltree check, you have to check it. That c++ have special language features did not mean that this can result in not checking that part of code which uses this features.

Klaus
  • 24,205
  • 7
  • 58
  • 113
  • 2
    You should be careful that you don't widen contracts so much that you can't change anything because every internal has a test that will break. You only test documented behavior that users can rely on, not every behavior that happens to show up. – nwp Sep 08 '17 at 09:28
0

You should test also for error cases, to be sure that the tested methods handle the error correctly (e.g. does the method really throws an exception or it just segfault under pressure?).

If you use gtest then you can test if a particular exception has been thrown by using EXPECT_THROW or ASSERT_THROW.

Paolo Brandoli
  • 4,681
  • 26
  • 38