<div dir="ltr">Hey,<br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 7, 2015 at 2:11 PM, Jan-Marek Glogowski <span dir="ltr"><<a href="mailto:glogow@fbihome.de" target="_blank">glogow@fbihome.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Am 07.10.2015 um 12:47 schrieb Stephan Bergmann:<br>
> On 10/07/2015 11:37 AM, Jan-Marek Glogowski wrote:<br>
>> I've implemented CPPUNIT_TEST_XFAIL to add test cases to a suite, which<br>
>> are expected to fail.<br>
><br>
> Do you have some explanation what this is good for?  (My assumption is<br>
> that one would just write the test code in a way that it is supposed to<br>
> succeed.)<br>
<br>
</span>The idea discussed in ESC was to allow developers to write tests for<br>
bugs, even if they are not able to fix them. We also assumed / hoped<br>
it's easier to write a test then fixing a bug. We'll see, if this turns<br>
out to be true.<br>
<br>
Most times this feature is used for test driven development, where you<br>
mark tests as expected to fail without breaking the build and when you<br>
actually fix the bug you simply remove the XFAIL from the test case. The<br>
idea is to prove you wrote a test for your bugfix.<br></blockquote></div><br><br></div><div class="gmail_extra">Please keep in mind that this is possible with the current cppunit already. The only difference (I'm not sure if that is really a useful feature) is that your patch set provides a log about how many of these tests have been executed.<br><br></div><div class="gmail_extra">CPPUNIT_TEST_FAIL already handles all the other requirements mentioned here. I had a discussion with Norbert about the usefulness of the new design as I think that the CPPUNIT_TEST_FAIL would have been enough already. I'll try to have a look into your patch set and at least remove all the changes to the existing API.<br><br></div><div class="gmail_extra">Regards,<br></div><div class="gmail_extra">Markus<br></div></div>