Closed Bug 750368 Opened 8 years ago Closed 8 years ago

Unable to run xpcshell tests locally


(Testing :: Mozbase, defect)

Not set


(Not tracked)



(Reporter: u408661, Unassigned)




(1 file)

This appears to be fallout from bug 746545

Running xpcshell tests on a new local clone fails because it can't find

> make SOLO_FILE=test_authentication.js -C obj-ff-dbg/netwerk/test/ check-one
make: Entering directory `/home/hurley/src/mozilla/mchg/obj-ff-dbg/netwerk/test'
/usr/bin/python2.7 -u /home/hurley/src/mozilla/mchg/config/ \
	  -I/home/hurley/src/mozilla/mchg/build \
	  /home/hurley/src/mozilla/mchg/testing/xpcshell/ \
	  --symbols-path=../../dist/crashreporter-symbols \
	  --build-info-json=../../mozinfo.json \
	  --test-path=test_authentication.js \
	  --profile-name=firefox \
	  --verbose \
	  /home/hurley/src/mozilla/mchg/obj-ff-dbg/dist/bin/xpcshell \
	  ../../_tests/xpcshell/netwerk/test/unit ../../_tests/xpcshell/netwerk/test/unit_ipc
Traceback (most recent call last):
  File "/home/hurley/src/mozilla/mchg/config/", line 52, in <module>
  File "/home/hurley/src/mozilla/mchg/config/", line 44, in main
    execfile(script, frozenglobals)
  File "/home/hurley/src/mozilla/mchg/testing/xpcshell/", line 48, in <module>
    import mozinfo
ImportError: No module named mozinfo
make: *** [check-one] Error 1
make: Leaving directory `/home/hurley/src/mozilla/mchg/obj-ff-dbg/netwerk/test'

Running tests in an old directory (one where you already ran xpcshell tests) works fine because there's a cached .pyc in build/ that is able to import.
I don't know if this is the right place to look for mozinfo, but it does allow me to run the tests.

Why do we copy everything into $obj/_tests and run it from there?
Attachment #619707 - Flags: review?(ted.mielczarek)
Comment on attachment 619707 [details] [diff] [review]
Help 'make xpcshell-tests' find 'mozinfo' Python module.

Review of attachment 619707 [details] [diff] [review]:

Files get copied around mostly for historical reasons, but partly because lots of tests want to load things like test XPCOM components. We could presumably refactor things to run mostly from the srcdir and just copy files as needed to the objdir, we just haven't gotten around to it.

::: config/
@@ -112,4 @@
>  # See also 'xpcshell-tests' target for global execution.
>  xpcshell-tests:
>  	$(PYTHON) -u $(topsrcdir)/config/ \
> -	  -I$(topsrcdir)/build \

There are a couple of invocations below that you'll need to fix as well. (check-one, check-interactive).
Attachment #619707 - Flags: review?(ted.mielczarek) → review+

Landed in fx-team, as mozilla-inbound is closed for Windows linker memory consumption; if this causes trouble, please let me know.
Flags: in-testsuite-
Target Milestone: --- → mozilla15
Is there a particular reason this was landed in fx-team instead of m-c? m-c is approval required, and given that (1) this won't alter the size of libxul, and (2) the patch solves a problem that could easily be seen by people cloning m-c, it seems to make more sense to get approval to land on m-c instead of a repo that not everyone works off of.
Closed: 8 years ago
Resolution: --- → FIXED
Backed out the latest fx-team merge whole-sale because of Ts regressions:

Please reland only after investigating and fixing the regression.  Thanks!
Resolution: FIXED → ---
I messed up and backed out the wrong range, sorry about that.  I backed out my backout, so this is still on mozilla-central:
Closed: 8 years ago8 years ago
Resolution: --- → FIXED
I have a similar problem with running xpcshell tests on windows with Thunderbird. I've tried making a similar change to our, but so far, no luck.
(In reply to David :Bienvenu from comment #8)
> I have a similar problem with running xpcshell tests on windows with
> Thunderbird. I've tried making a similar change to our, but so far,
> no luck.

David, let's track the comm-central failure on if you don't already have a bug for it.
Blocks: 752252
You need to log in before you can comment on or make changes to this bug.