Policy proposal: don't add tests with names that only include bug numbers and no description

Dave Camp dcamp at mozilla.com
Wed Sep 18 16:54:52 UTC 2013

Honestly, I prefer if the bug number isn't in the filename at all.  Tab
completing specific tests is just more annoying if you're globbing or
whatever around bug numbers.

I'll check the comments if I need a bug number.


On Wed, Sep 18, 2013 at 9:23 AM, Gijs Kruitbosch
<gijskruitbosch at gmail.com>wrote:

> TL;DR: I'd like to propose having a policy to require new tests (or
> updates to existing tests) to have descriptive file names - which means
> more than just a bug number.
> Longer explanation: some of us were talking on IRC about how we have lots
> of tests that have filenames that only have a bug number as useful
> information. For example:
> $ ls -1 browser/base/content/test/ | grep 'browser_bug[0-9]*.js' | wc -l
> 108
> Of course, bug numbers are useful because then we can read descriptions on
> bugzilla. But TBPL, my terminal window, and the MXR directory listings are
> not bugzilla.
> In other word, this makes it harder to know what tests are testing, and to
> split them up into directories that make topical sense. Furthermore, if a
> test breaks, it's not immediately obvious whether the breakage is topical
> to that test, the fault of that test itself or some other test that ran
> earlier, and if it's some other test: which tests are or are not likely
> suspects for having broken assumptions of tests running after themselves.
> Gavin suggested we could just have a policy to require test filenames to
> be more than just bug numbers. I concur. How do others feel about this?
> ~ Gijs
> ______________________________**_________________
> firefox-dev mailing list
> firefox-dev at mozilla.org
> https://mail.mozilla.org/**listinfo/firefox-dev<https://mail.mozilla.org/listinfo/firefox-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20130918/211c5110/attachment.html>

More information about the firefox-dev mailing list