Re: [boost] Unittest capability for meta-programs feedback request

Subject: Re: [boost] Unittest capability for meta-programs feedback request
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2011-09-28 07:23:31

Le 27/09/11 21:18, Gennadiy Rozental a écrit :
> Dave Abrahams<dave<at>  boostpro.com>  writes:
>
>> Sometimes, however, there's no compile-time bool to work with.
>>
>> If I am the author of std::pair and I write:
>>
>>    // test that pair doesn't somehow convert unrelated types
>>    // into values that can be used for construction
>>    std::pair<int,int>  x("foo", "bar");
>>
>> I expect that test to fail compilation.  There's no useful assertion you
>> can do that will turn it into a runtime error.
> Yes. There are always some implied/implicit expectations. And I also do not see
> any way to make it into a testable concepts since it belongs to a member
> function, unless we can come up with a means to attach concept to the member
> function. In that case we would have checked
>
> std::pair<int,int>::pair<std::string,std::string>::concept
>
>
>>>> Personally I am very uncomfortable with the use of exceptions to deal
>>>> with failed assertions, and in a test that's just a bunch of
>>>> compile-time assertions, I don't see *any* advantage whatsoever in using
>>>> exceptions.
>>> This is usual deal with unit tests: you want to test all the
>>> expectations.
>> Yes
>>
>>> Imagine you expect that your component does not work with int. Meaning
>>> MyComponent<int>  should fail to compile.
>> Yes.  This is the kind of case I'm talking about.
>>
>>> How can you record and test this expectation? In original version - no
>>> way to do this.
>> Hm?  Original versoin of what?
> of MyComponent implementation in my first reply.
>
>>> Your only option is to put into test module some test statements and
>>> comment them out.
>> We do it today by having "expected compilation failure" (compile-fail)
>> tests (a more robust system would test the contents of the error
>> message, but that's another thing).
> Yes. There is this option, but it's hardly robust. You can't be sure it fails to
> compile for a reason you expect it to and checking against compiler output is
> frankly madness. Not only it's different for different compilers, but it also
> tend to change with every modification of component implementation.
>
>>> Now imagine that you or someone else changes implementation of the
>>> component and suddenly MyComponent<int>  compiles. Your original
>>> expectation is broken. And yet your test module does not notify about
>>> it.
>> Not mine; I build a compile-fail test.
> In practice there are few people who rely on these.
A lot of Boost authors relay in this technique
> Having compilable, runtime
> reportable and robust alternative would be of use for everyone else.
I recognize the utility of such a system, what I don't like is the 
complexity it introduce in the implementation. If some one find a way to 
report these compile failures at runtime without needed to refactor too 
much the intended implementation I will be the first to adhere to it.
>>> Now if you can come up with another approach to test these
>>> expectations I'd be happy to listen.
>> We already have an approach; it requires integration with the test
>> system.  Yes, it's imperfect, but it does do the kind of testing needed
>> to see that MyComponent<int>  is prohibited.
> Again very few users have testing system smart enough even to recognize
> "expected compile failure" tests. And I personally would not use it if I can
> help it.
>

Having a build system that check failure of compilation is quite easy. 
This doesn't needs nothing too much smart.

In order to be more confident that the compile failure corresponds to 
the expected one you could start with an archetype of the concept and 
test that it compiles. The you can remove one at a time each one of the 
requirements and check that the program doesn't compiles any more.

Best,
Vicente