[Development] Removal of some of the blacklisted (non-working) autotests?
Jędrzej Nowacki
jedrzej.nowacki at qt.io
Fri Nov 4 09:10:01 CET 2016
On torsdag 3. november 2016 09.17.57 CET Milla Pohjanheimo wrote:
> I would like to challenge you a bit about removal of (some of) the
> blacklisted autotests.
> (...)
Hi,
In your email you wrote that blacklisted is just a burden for CI. In
general it is true, but mark that currently they are compiling and they are
_not_ crashing. So they do contribute to the quality of Qt. On the other hand
they artificially increase test coverage level hiding untested code paths and
they may affect other tests.
Partial conclusion: delete them, but watch code coverage and add new ones
where needed.
Eddy mentioned that tests are documenting certain Qt usages. There are two
aspects of it. In many cases, we do not know what author of a test wanted to
test, sometimes it was a use case, sometimes it was just an internal code path
in the implementation. On the other hand, we know that the code is not working
in a reliable way, therefore in reality it is a misleading documentation.
Moreover developers tends to do copy&paste coding and coping a blacklisted
test is just plain wrong, while being very difficult to catch in code review.
Partial conclusion: delete them, but add a policy that every test should
contain a short comment what is the purpose of the test.
Some tests are blacklisted only on certain platforms. Depending on the reason
why the test is not working on a specific platform, we need to handle them
differently. In general it is ok to assume that Qt as well as Qt bugs are
cross platform. So a test failing only on one of them is failing because of a
platform specific code (we do not have so much of it) or it is wrongly
blacklisted or it hits a bug in a platform itself.
Partial conclusion: the test delivers an interesting information. It is worth
to spend a bit of time and check what is going on. A tool that do a stress
test of a test would be a really good addition, as it would simplify
debugging.
Conclusion: I believe we should delete them, but be smart about that. Don't
just go and remove all of them, but first build infrastructure / process that
allows us to not decrease the test coverage. Even more, we need something that
would not allow flaky, badly written test to be merged to Qt in the first place,
otherwise we would have that discussion again in next 12 months.
Cheers,
Jędrek
More information about the Development
mailing list