Closed
Bug 1157852
Opened 9 years ago
Closed 9 years ago
Mochitest DevTools test directories run multiple times
Categories
(Testing :: Mochitest, defect)
Testing
Mochitest
Tracking
(firefox40 fixed)
RESOLVED
FIXED
mozilla40
Tracking | Status | |
---|---|---|
firefox40 | --- | fixed |
People
(Reporter: jryans, Assigned: jmaher)
Details
Attachments
(1 file, 1 obsolete file)
1.21 KB,
patch
|
jmaher
:
review+
|
Details | Diff | Splinter Review |
When I run "mach mochitest-devtools browser/devtools/webide", I see: dir: browser/devtools/webide/test The tests in this directory are run, plus those in browser/devtools/webide/test/sidebars dir: browser/devtools/webide/test/sidebars The tests in only this directory are run again, even though they already ran in the context of the parent directory above. Are these test directories misconfigured in some way, or is the test runner duplicating work?
Comment 1•9 years ago
|
||
This is either run-by-dir or chunking fallout, but I don't know which.
Assignee | ||
Comment 2•9 years ago
|
||
odd, looking in my inbound clone, sidebars has no tests within it- for runbydir if there is a directory that has no tests we do not run it. quite possibly :jryans is adding tests to browser.ini in the sidebars/ directory. more to investigate.
Assignee | ||
Comment 3•9 years ago
|
||
here is the problem: https://dxr.mozilla.org/mozilla-central/source/testing/mochitest/runtests.py#2106 tests_in_dir = [t for t in testsToRun if t.startswith(d)] no idea if this is runbydir or new chunking- I would like to think the latter, but who knows. How to fix this? The original idea behind runbydir is to get all tests from a given manifest and run them. more of a runbymanifest. One thing is we could do tests_in_dir = [t for t in testsToRun if dirname(t) == d] ^ that would remove tests in a contained subdir. how would this work if the root manifest was the only thing to include the submanifest? For this specific webide/test/ directory, it would work as there is a browser.ini in the sidebars subdir. thoughts anyone?
Flags: needinfo?(ahalberstadt)
Comment 4•9 years ago
|
||
(In reply to Joel Maher (:jmaher) from comment #3) > One thing is we could do > tests_in_dir = [t for t in testsToRun if dirname(t) == d] Yeah, I think that's the proper fix. Though I'm not really sure how (if?) this was working before, because the old options.testPath method also used startswith: https://dxr.mozilla.org/mozilla-central/source/testing/mochitest/runtests.py#1962 > ^ that would remove tests in a contained subdir. how would this work if the > root manifest was the only thing to include the submanifest? For this > specific webide/test/ directory, it would work as there is a browser.ini in > the sidebars subdir. Running ./mach mochitest <test_path> uses options.testPath to filter down tests (see dxr link above). So as long as the test is in a subdirectory of <test_path> and is included by a manifest (and not skipped), it should get run. This is the behaviour of options.testPath with or without runByDir.
Flags: needinfo?(ahalberstadt)
Assignee | ||
Comment 5•9 years ago
|
||
Comment 6•9 years ago
|
||
Comment on attachment 8597317 [details] [diff] [review] only run tests from a given dir, not the subdirs (1.0) Review of attachment 8597317 [details] [diff] [review]: ----------------------------------------------------------------- r+ with comment fixed. ::: testing/mochitest/runtests.py @@ +2102,5 @@ > if inputTestPath and not inputTestPath.startswith(d): > continue > > print "dir: %s" % d > + tests_in_dir = [t for t in testsToRun if '/'.join(t.split('/')[:-1]) == d] I think you're looking for os.path.dirname. Also it might be a good idea to run them both through "os.path.normpath": https://docs.python.org/2/library/os.path.html#os.path.normpath
Attachment #8597317 -
Flags: review?(ahalberstadt) → review+
Assignee | ||
Comment 7•9 years ago
|
||
carry forward the r+, thanks for the os.path.dirname, it works in local testing. let me do a nice try push before landing.
Attachment #8597317 -
Attachment is obsolete: true
Attachment #8597347 -
Flags: review+
Assignee | ||
Comment 8•9 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=26c10f401933
Comment 10•9 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/bcfc39710995
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
status-firefox40:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
You need to log in
before you can comment on or make changes to this bug.
Description
•