action #10704
open
Make warnings in tests fatal
Added by okurz over 8 years ago.
Updated over 3 years ago.
Category:
Feature requests
Description
user story¶
As an openQA developer I want openQA unit and integration tests to fail when warnings are encountered to ensure not introduce regressions
acceptance criteria¶
- "make test" fails if new warnings are encountered
- the existing warnings are fixed or properly marked and skipped
tasks¶
- It should help if we first fix all existing warnings to make new ones more visible
- research how to make "prove" catch warnings and make them fatal
- why does "prove -W" ("") not work as I expect it?
- decide on an approach
- make warnings fatal in all tests
- fix existing warnings
further notes¶
- Description updated (diff)
- Status changed from New to In Progress
- Assignee set to okurz
- Status changed from In Progress to Resolved
- Status changed from Resolved to In Progress
no, wait, need to do the same for os-autoinst
on hold, anyone else can take over and fix that for os-autoinst. easy task as openQA is already done and can be used as reference :-)
- Assignee set to rpalethorpe
- Assignee deleted (
rpalethorpe)
- Status changed from In Progress to New
- Target version set to future
- Target version changed from future to future
- Category changed from 132 to Feature requests
- Priority changed from Normal to Low
We use Test::Warnings in most test modules within os-autoinst as well as openQA with good success. We do not have a check that Test::Warnings is used everywhere and also we do not have good reporting about warnings from tests or so, this can still be done.
- Status changed from New to Feedback
- Assignee set to okurz
I suppose the conversation is still on-going with regard to the implications of making runtime warnings fatal and how to expose them (as can be seen in the PR review comments).
you can say so. The last comment was from just 5 days ago and I wanted to read about what Linus wrote in the linked mailing list post :)
Are you still pursuing the proof of concept with strictures?
well, no action was done since the last comment and nothing changed. I could just unassign but I still have my ticket open and it's in "future" so I think no one else is more likely to pick it up when it's done and the ticket is "Low" so I don't think anything needs to be changed. Unassigning and eventually reassigning would just be noise. As long as you still consider myself a useful member of the team I guess we can keep it this way :)
- Related to action #78240: prevent circular dependencies in bmwqemu.pm and autotest.pm to be able to use "strictures" added
- Status changed from Feedback to New
- Assignee deleted (
okurz)
- Copied to action #108503: Collect and prominently display warnings from autoinst.log added
Also available in: Atom
PDF