TB24 inclusion for new minor feature (thread-sorting pref)

The Wanderer wanderer at fastmail.fm
Mon Aug 12 16:09:34 UTC 2013

On 08/12/2013 11:25 AM, Andrew Sutherland wrote:

> On 08/12/2013 08:32 AM, The Wanderer wrote:
>> B, the most closely related existing tests (and thus, most
>> adaptable existing code) are xpcshell-based - but not only does
>> this not sound like the sort of test which fits under the umbrella
>> of what MDN describes as xpcshell's domain, I don't have my head
>> around xpcshell. At the very least, I'd probably need a fair bit of
>> hand-holding through parts of the process.
> http://mxr.mozilla.org/comm-central/source/mailnews/base/test/unit/test_nsMsgDBView.js
> which is probably what you found is indeed the right place to test
> this.  Specifically, it's preferable to test nsMsgDBView code in
> mailnews tests rather than Thunderbird-specific tests.  It's also
> preferable to test it using xpcshell since there are a number of
> permutations that affect it and by testing it in relative isolation
> allows it to be directly driven without worrying about things that
> should be irrelevant to the test (like screen size), higher level
> abstractions like the DBViewWrapper or FolderDisplayWidget, etc.

Acknowledged; that does answer a couple of questions I'd had. That is
indeed what I found.

> There is some documentation on the framework used in that test here:
> https://developer.mozilla.org/en-US/docs/MailNews/AsyncTestUtils_Extended_Framework
> In terms of your debug cycle; you absolutely shouldn't need to do a
> clean make every time you want to run the test.  The test files
> should be symlinked.

Indeed, re-running the test does not require rebuilding; the extra steps
come in mainly when I need to update against the upstream tree, since I
can't build in my test environment (and can't pull directly from
upstream in my build environment without partly tying myself to that
environment even for when I no longer need it).

I'd neglected to notice that the fact that the test is JS means changes
to it wouldn't have to be rebuilt to be tested, so that should indeed
make things much faster and easier than I'd thought. Thanks for pointing
that out.

> You should be able to just re-run the test after changing the JS file
> as per the yellow box about "check-one" at the top of
> https://developer.mozilla.org/en-US/docs/Writing_xpcshell-based_unit_tests.
> It sounds like you found that box, but there are extenuating
> circumstances per your comment in
> https://bugzilla.mozilla.org/show_bug.cgi?id=890877.  My suggestion
> would be to use 'make' to build instead; the 'mach' support in
> comm-central is very new, so it's not entirely surprising that it
> would die on things other than straight-up Ubuntu or the like, but I
> understand how badly that sucks and what a frustrating maze it can
> be :(

Actually, I haven't been able to get the xpcshell tests to run at all
with mach, as far as I recall. The only way I've been able to get them
to run is

   cd obj-*
   make xpcshell-tests

I've tried variants with 'check-one' and 'SOLO_FILE' and so forth, as
documented on the page you referenced, and they either don't run
anything (often with errors about "no rule to make target such-and-such"
or a missing xpcshell.ini file) or re-run all the xpcshell tests instead
of just the one I asked for.

Admittedly, the actual build I did do with mach; would that affect the
results of the ways to run xpcshell tests?

I'll look into getting the actual build done with make next time I look
at this, probably tonight. (I have to leave for work shortly.)

    The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Every time you let somebody set a limit they start moving it.
   - LiveJournal user antonia_tiger

More information about the tb-planning mailing list