Closed Bug 1041485 Opened 10 years ago Closed 10 years ago

Running a single mochitests-plain test always returns "unknown test url" and doesn't show test message

Categories

(Testing :: Mochitest, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1041708

People

(Reporter: martijn.martijn, Assigned: martijn.martijn)

References

Details

Attachments

(1 file)

Attached patch simpletest.diffSplinter Review
When running a single mochitest-plain, I get as result:
83 INFO unknown test url | TEST-PASS |
This is rather unhelpful.
It is pretty clear which test I'm running (since I would specifiy it in a single test run), so that's not so important.
But getting the test message would be helpful.

This patch fixes it. Afaict, this patch only touches code that would run in a single test run, so it should be safe in general.
The use of the subtest variable is defined in _logResult:
    var subtest = test.name ? String(test.name) : null;
Attachment #8459530 - Flags: review?(jmaher)
Comment on attachment 8459530 [details] [diff] [review]
simpletest.diff

Review of attachment 8459530 [details] [diff] [review]:
-----------------------------------------------------------------

::: testing/mochitest/tests/SimpleTest/SimpleTest.js
@@ +318,1 @@
>             "unknown test url";

can you add parens around this so we have exact conditions here.  Right now we have a lot of || and && conditions, which gets evaluated, this should be clear.

won't we always have window.location.pathname just with the index page?

@@ +362,5 @@
>                                                   result.status,
>                                                   result.expected,
>                                                   diagnostic);
>      } else if (typeof dump === "function") {
> +        var debugMsg = [url, result.message, subtest].join(' | ');

so we now don't print diagnostic at all?  I don't like us removing that functionality.  Could we print subtest if diagnostic is null?
Attachment #8459530 - Flags: review?(jmaher) → review-
(In reply to Joel Maher (:jmaher) from comment #1)
> @@ +362,5 @@
> >                                                   result.status,
> >                                                   result.expected,
> >                                                   diagnostic);
> >      } else if (typeof dump === "function") {
> > +        var debugMsg = [url, result.message, subtest].join(' | ');
> 
> so we now don't print diagnostic at all?  I don't like us removing that
> functionality.  Could we print subtest if diagnostic is null?

This code is only being run when it is run as a standalone test. Apparently, diagnostic is always null when running as a standalone test. I have no idea why. I don't know what diagnostic is supposed to be, to be honest.
(In reply to Martijn Wargers [:mwargers] (QA) from comment #2)
> This code is only being run when it is run as a standalone test. Apparently,
> diagnostic is always null when running as a standalone test. I have no idea
> why. I don't know what diagnostic is supposed to be, to be honest.

I guess this happens because of:
http://mxr.mozilla.org/mozilla-central/source/testing/mochitest/tests/SimpleTest/SimpleTest.js#236
SimpleTest.ok = function (condition, name, diag) {

Where diag is passed along, and eventually becomes this diagnostic variable.
It looks weird to me, because most of the the SimpleTest.ok is being used with just 2 arguments in tests.
Bug 1041708 is the same and that one has an r+-ed patch, so marking it duplicate of that one.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Actually, bug 1041708 doesn't fix "unknown test url" being logged when no parentRunner is present. (it only fixes the missing message / wrong log format issue)

Are we sure that window.location.pathname will always be the path to the test we're executing? If we are, it may be interesting to land a patch with that change only.
(In reply to Ahmed Kachkach [:akachkach] from comment #5)
> Are we sure that window.location.pathname will always be the path to the
> test we're executing? If we are, it may be interesting to land a patch with
> that change only.

I would think so, but I don't know. Anyway, it's not a big deal, because anyone running a single test would already know which test they are executing.
See Also: → 803284
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: