Reputation: 13327
I've written a Matrix class, and checked that it disallowed multiplication of matrices of incompatible sizes using C++ exceptions. I wrote unit tests to check that behavior, and they are expecting exception to be thrown.
Now I'm changing the Matrix size from being a runtime variable to a template parameter. If I'll be able to do that correctly, the code that will try to multiply matrices of wrong sizes won't even compile.
It would seem that now these unit tests are redundant. However, since I don't know how I'll change my code in the future, and what will break, I still want to implement tests for this. If before I expected my tests to throw specific exceptions at specific places, now I want my test to throw specific compile errors at specific places.
What's the best way to do that? I would imagine some sort of mechanism based on Makefile and shell scripting that would wait for a specific error codes — or should I try something else? Is this idea a common practice or complete madness?
Edit: Of course, "Unit tests" isn't a fitting name for this kind of mechanism, I know that, but for now, I just can't think of a better way. There are already three comment authors who spent their valuable time and effort explaining to me what unit tests are and what they aren't. Unfortunately, while being technically true, this doesn't help to solve an actual problem at hand here.
Edit 2: This is BDD scenario that I want to test for:
Before, that error was runtime error, and it testing for it was trivial. But now I it became a compile time error, and I don't see how I can keep automatically testing this scenario and confirming, on every commit (I have unit tests in my git hooks) that it still gives me an error.
Upvotes: 8
Views: 1725
Reputation: 2221
I don't yet have enough Rep to comment on @Paul Evans' answer so please tell me if I should've just not answered.
@Paul Evans recommends DejaGnu and I support that choice.
However if you want to produce more intelligible compile errors (template compile errors tend to get messy) you could use static_asserts
.
They are standard since c++11 (though you should check if your compiler can use them) and are akin to traditional asserts, only they are checked at compile time and can display a custom error message.
Here's the documentation if you want to check them out : http://en.cppreference.com/w/cpp/language/static_assert
Upvotes: 0
Reputation: 27577
It's harmless to keep your "unit" test, even if the new template
style of code makes it "impossible" to mismatch matrix's at run time. You may still have a bug that gets through to run time and, as you say, the code could change again.
If you're using gcc
, gcc
uses DejaGnu to test itself. That should be robust enough to detect gcc
compilation errors.
Upvotes: 1