我编写了一个Matrix类，并检查它是否禁止使用C ++异常对不兼容大小的矩阵进行乘法运算。我编写了单元测试来检查这种行为，并且他们期望抛出异常。
现在我将Matrix大小从运行时变量更改为模板参数。如果我能够正确地做到这一点，那么试图将错误大小的矩阵相乘的代码甚至都不会编译。
现在看来这些单元测试是多余的。但是，由于我不知道将来如何更改我的代码，以及会破坏什么，我仍然希望为此实现测试。如果在我预期我的测试在特定位置抛出特定异常之前，现在我希望我的测试在特定位置抛出特定的编译错误。
最好的方法是什么？我会想象某种基于Makefile和shell脚本的机制会等待特定的错误代码 - 或者我应该尝试别的东西？这个想法是一种常见的做法还是完全疯狂的？
编辑：当然，“单元测试”不是这种机制的合适名称，我知道，但就目前而言，我想不出更好的方法。已经有三位评论作者花了他们宝贵的时间和精力向我解释了什么是单元测试，哪些不是。不幸的是，虽然技术上是正确的，但这无助于解决手头的实际问题。
编辑2 ：这是我要测试的BDD场景：
之前，错误是运行时错误，并且测试它是微不足道的。但现在我成了一个编译时错误，我不知道如何能够自动测试这个场景并确认，在每次提交时（我在git hooks中都有单元测试）它仍然给我一个错误。
答案 0 :(得分：1)
保持你的＆＃34;单位＆＃34;是无害的。测试，即使新的template代码风格使它“不可能”＃34;在运行时不匹配矩阵。您可能仍然有一个错误可以通过运行时间，正如您所说，代码可能会再次更改。
如果您正在使用gcc，gcc会使用DejaGnu来测试自己。这应该足够强大，可以检测gcc编译错误。
答案 1 :(得分：0)
我还没有足够的评论对@Paul Evans的回答发表评论，所以请告诉我是否应该回答。
@Paul Evans推荐DejaGnu，我支持这个选择。 但是，如果您想要产生更易理解的编译错误（模板编译错误往往会变得混乱），您可以使用static_asserts。
它们是标准的，因为c ++ 11（虽然你应该检查你的编译器是否可以使用它们）并且类似于传统的断言，只有它们在编译时被检查并且可以显示自定义错误消息。
以下是文档，如果您想查看它们：http://en.cppreference.com/w/cpp/language/static_assert