Randa 2011 Metting Idea Dump

[Milian Wolff]

Andreas Pakulat, 06.06.2011:
> On 06.06.11 12:31:23, Milian Wolff wrote:
> > greetings from the last day of our 2011 sprint in Randa. If you missed
> > it, I've logged some results of our discussions on the following wiki
> > page:
> > 
> > http://techbase.kde.org/Projects/KDevelop4/Meeting2011
> > 
> > There is lots of stuff TODO in there (some lines are flagged with that,
> > some not...). Look at it as a memory of stuff we want to do in the
> > future. Furthermore there are rough experimental ideas in there which we
> > want to investigate. Also some items could be used for future
> > contributors to work on, i.e. if we get more awesome French students
> > next year, of for GSOC.
> > 
> > Anyways, if someone has questions, shoot. Keep in mind that many of these
> > bullet points are not set in stone.
> 
> That point about "never submit failing unit tests" needs more
> explanation  I think, it seems to encourage simply putting in a
> QEXPECT_FAIL if a code-change breaks a unit-test or if a newly-written
> test triggers a bug in the code. It should be made clear that
> QEXPECT_FAIL is only to be used _if_ the test wants to verify that a
> certain assumption is not true, i.e. the expected behaviour is a fail
> even though all the code is correct.

Yes and no. I have the habit of writing a test for a bug, and since there is a 
bug the test will fail. Hence QEXPECT_FAIL to mark this test as just that - an 
expected failure. Afterwards I fix the bug and remove the QEXPECT_FAIL.

This is how it is supposed to be used and afair a very common technique. Wine 
e.g. has this requirement for all unit tests or at least similar to this.

The only problem is crash-bugs. You cannot QEXPECT_FAIL that. Still, better a 
crashing unit test than no test at all.

> It shouldn't be used to just silence failing tests, as then the tests
> are completely useless.  Better to disable the test alltogether than
> making it 'succeed' even though its actually failing.

Yes, that is of course true. I'll create a proper policy page on techbase or 
on our website.
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20110606/9e93f5ff/attachment.sig>