#30284 closed task (blessed) (fixed)
Remove failing automated tests from the suite
Reported by: | boonebgorges | Owned by: | |
---|---|---|---|
Milestone: | 4.2 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Build/Test Tools | Keywords: | |
Focuses: | Cc: |
Description
Our previous convention was to write unit tests to demonstrate bugs, annotate those tests with a @ticket
flag, and commit them to the repo. Then, when running the suite, WP_UnitTestCase::knownWPBug()
would get a list of open tickets from Trac, and skip tests against open tickets, allowing the build to pass. This convention is not ideal for a couple reasons:
- It requires fetching a report from Trac on every run of the suite. This adds a couple seconds to each run of
phpunit
, which can be a real drag when using TDD techniques. (It also causes miscellaneous problems with transports and offline access - see https://buddypress.trac.wordpress.org/changeset/9053 for an illustration.) - When you skip failed tests by default, you have to do things like
phpunit --group 12345
to get them to run during development. This, in turn, can mask certain kinds of pollution between new and old tests, pollution that may not show up until after commit. See [30112] and [30148] for a couple of recent examples. - In terms of developer psychology, committing a failing test is a way of washing one's hands of an issue: "look, I've documented the bug, and now I can move on".
The new convention is to commit tests only when fixing the bug. But this leaves dozens of failed tests in the repo. These tests should be pulled out, converted to patches, and uploaded to their relevant Trac ticket with a note indicating what's just happened. Once all the failed tests are out of the repo, we can remove the knownWPBug
behavior from the test runner.
Attachments (20)
Change History (71)
This ticket was mentioned in Slack in #core by boone. View the logs.
10 years ago
#4
@
10 years ago
The zip I attached contains a bunch of patches removing tests with @ticket. I am going to go back through and add the tests back that have closed tickets and pass.
#5
@
10 years ago
Thanks, MikeHansenMe. This is a helpful start, but what would be *really* valuable is this: for each ticket that is currently being skipped, generate a patch that removes the test (that's what we'll commit) as well as another one that *adds* the tests (that's the one that will be attached to the open ticket for future reference). This is admittedly an easier workflow for a committer. But you could do it fairly easily with a git stash.
#6
@
10 years ago
MikeHansenMe - Thanks for your continued work on this. I'm looking through these tests, and it looks like many of them are actually passing when forced to run. We don't need to remove passing tests from the suite - just those that fail because they demonstrate an unfixed bug. Sorry if that wasn't clear from the discussion above. (This, by the way, points to another problem with the "skipping" behavior: it causes tests to be skipped when they're good, passing tests, just because they're attached to a ticket that happens to be open for some reason.) So, a good technique for collecting these might be to set WP_FORCE_KNOWN_BUGS
to true, and then start removing the tests that fail.
This ticket was mentioned in Slack in #core by boone. View the logs.
10 years ago
This ticket was mentioned in Slack in #buddypress by boone. View the logs.
10 years ago
#16
@
10 years ago
Do not delete test_unregistered_shortcodes(). If you have test feedback please put it on the appropriate ticket or message me directly on Slack.
#17
@
10 years ago
@microgroove - Keeping purposefully failing tests in the repo no longer makes sense. Back when we had two separate repositories and two separate tracs, it made sense to commit unit tests that we knew weren't going to pass. At that point, tests and our core code were essentially two separate projects. Now that we have combined them into one, it no longer makes sense. Our tests are as core to our project as any other piece of code we have.
That said, all the tests marked for 29557 are currently passing in trunk for me (even though the ticket is open for other reasons), so I have no intention of removing them. The work on this ticket is to make sure that we always run those tests even though the ticket is open (so we don't inadvertently break that code with other changes).
#18
@
10 years ago
The comments above said unit tests would be removed for all open tickets. Just wanted to clarify that.
This ticket was mentioned in Slack in #core by boone. View the logs.
10 years ago
This ticket was mentioned in Slack in #buddypress by boone. View the logs.
10 years ago
#42
@
10 years ago
- Milestone changed from Future Release to 4.2
- Resolution set to fixed
- Status changed from new to closed
All failing tests, and most skipped tests, have been removed from trunk. The only remaining skipped tests are those that depend on environment: tests that can only run with a certain PHP or Apache configuration, ones that can only run with/without Multisite, etc. This is a proper use of test skipping, so they stay.
There are a few places where Travis CI is skipping tests because the environment is not set up properly. This warrants a separate ticket. Marking this one resolved.
I think for the failing tickets, we should reattach the tests to the existing ticket so that we don't lose them when/if they are fixed. One we have done that, we can remove the code that checks to see if the tickets are open. I say we start doing that and reference this ticket, along with the one that we are removing tests for in the all red commit.
I do think @ticket should be kept as a notation, but we also should generally be frugal with groups and make them as needed since they can help encourage test driven development.