1

Is there an easy/recommended way to automate testing of code that should not compile actually not compiling? For example, I have something like this under GTest:

TEST(Foo,Bar)
{
 EXPECT_TRUE( func1() );
 Foo  x(1.0);
 Foo::Bar<double> good(x);

#if 0 // should not compile with rvalue ref!
    Foo::Bar<double>  crashGetter(Foo(1.0));
#endif
}

Can the "change to #if 1, try to build, verify it still fails, put back #if 0" be automated for testing?

EDIT: this related question has someone more useful answers: "how-to-unit-test-deliberate-compilation-errors"

EDIT: This test is not for myself. The scenario I want to guard against is someone else hitting a compiler error, going in and "fixing" the header that #include'd and thinking "cool the unit tests still pass", thus leading to subtle bugs appearing as Rvalue refs get used wrongly in more and more code.

EDIT: best similar Q suggested by comments: How to unit test deliberate compilation errors?

Community
  • 1
  • 1
peter karasev
  • 2,578
  • 1
  • 28
  • 38
  • everything easy probably involves driving external scripts that test for compiler returns and maybe some numbered ifdefs that get passed from it – PlasmaHH May 16 '14 at 15:16
  • what test tool do you use? EDIT: sorry, I overlooked that you already stated that – MikeMB May 16 '14 at 15:20
  • 1
    You may use lib clang and try to compile a buffer... – Jarod42 May 16 '14 at 15:21
  • The short answer to my question seems to be *NO* there is not an easy way. You might be able to get the desired effect with type_traits and static_assert. But, to truly test that a compiler error happens for some semantic misuse of the types, a separate build area must get set up where the compiler is called on offending code and you can check that object files were not written. That's an awful lot of effort when the types are in a big project. You'd need a separate build area for each "bad line" test to accurately diagnose test failures... – peter karasev May 17 '14 at 00:34
  • It's pointless. You should be testing your own production code, not the platform. You're entitled to rely on compiler certification testing for this sort of thing. – user207421 May 17 '14 at 01:43
  • @EJP I am testing my own production code. The scenario I want to guard against is someone hitting a compiler error, going in and "fixing" the header that #include'd and thinking "cool the unit tests still pass", thus leading to subtle bugs appearing as Rvalue refs get used wrongly in more and more code. – peter karasev May 18 '14 at 22:33
  • 2
    you may try `decltype` combined with SFINAE and `static_assert` to get compiler error if something unexpected compiled – Bryan Chen May 18 '14 at 23:56
  • 1
    Closing as a dupe seems appropriate, but I don't agree with the question that was selected as the original. This one seems better aligned with the intent of this question: http://stackoverflow.com/questions/7282350/how-to-unit-test-deliberate-compilation-errors – Adrian McCarthy May 21 '14 at 15:56
  • @AdrianMcCarthy yep that's the best similar link. I'd accept the comment above as an "answer". – peter karasev May 22 '14 at 02:47

0 Answers0