<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Sep 5, 2016 at 4:11 AM, Mike de Boer <span dir="ltr"><<a href="mailto:mdeboer@mozilla.com" target="_blank">mdeboer@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
>><br>
>> As I did over IRC, I would like to strongly object to the continued use<br>
>> of per-test-type subfolders in our test directories. You can already use<br>
>> a specific mach command per test type, and the tests are listed in<br>
>> different manifests, *and* there's all the different filename<br>
>> conventions (browser_, test_....html, test_....xul, <whatever>.js) that<br>
>> further point out what type of test you're looking at. The subfolders<br>
>> add nothing useful.<br>
><br>
> As someone who has been adding the directory levels to toolkit/components/passwordmgr<wbr>/test/ recently, I disagree with this since they add a grouping of relevant files making it more obvious which files go with which test suites.<br>
><br>
> * Chrome mochitests, plain mochitests and xpcshell share the same prefix (test_) so they are interleaved together in directory listings.<br>
> * Files that accompany tests have no prefix convention.<br>
> * head.js files have no indication of what suite they're for (i.e. no prefix)<br>
> * `mach test` doesn't support specifying a flavor of mochitest.<br>
> * Changing the subdirectory of my `mach mochitest` command is usually faster than adding the flavor argument since the path is usually at the end of the command. Since `mach test` doesn't support the flavor argument I don't have to remember whether to use the argument or change the path as I can always change the path when directories are used.<br>
> * xpcshell and browser-chrome both use "head.js" as the filename for helpers though they run in very different contexts.<br>
><br>
> For a new contributor, having each suite in their own directory is much less confusing/overwhelming for the above reasons.<br>
><br>
> Password Manager may be special in that it's using four different suites so I'm not suggesting that every component needs to put their tests in a subdirectory named after the test suite but I don't think we should be dumping tests of different suites in one directory unless the distinction between files would be clear to a newcomer.<br>
<br>
</span>I think that sub-dividing unit test per-suite/ runner is the wrong way to go, especially for new contributors. It imposes the use and knowledge of jargon that is utterly unnecessary and uninspiring.<br>
Instead, I believe the nicest way to sub-divide tests is by trying (a bit) harder to categorize them better:<br>
<br>
NO: /browser/components/sessionsto<wbr>re/test/marionette/<br>
YES: /browser/components/sessionsto<wbr>re/test/startup/<br>
<br>
NO: /browser/components/sessionsto<wbr>re/test/xpcshell/<br>
YES: /browser/components/sessionsto<wbr>re/test/cookies/<br>
<br>
NO: /any-path/test/general/<br>
YES: /any-path/test/+1-level-up-cre<wbr>ative-sub-category/<br>
<br>
<br>
I suppose that means that I’m strictly opposed to moving the tests, but that’s not the case; having relevant unit tests closer to the metal is a net improvement, whichever way you look at it.<br>
It is, however, I great moment to look up and introspect decisions from the long forgotten past to see if we can do better. (Hint: of course we can! Wouldn’t be much fun otherwise, now would it?)<br></blockquote><div><br></div><div>Naming things is hard and one of the more difficult problems in computer science.<br><br>You raise valid points that our testing is overly complicated, with N variations of tests and corresponding ways to name them.<br><br></div><div>From a UX perspective, you have to pick the audience you are optimizing for. If you optimize for running tests, you probably put everything in one giant bucket/directory and/or lean on the tagging system in test manifests to logically group related tests to make them easier to run. Then you just tell people "run `mach test my-feature` or `mach test path/to/my/component`" and magic ensues. If you optimize for writing and maintaining tests, then you start wanting a naming convention.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Let’s file some bugs and get the ball rolling! Also, let’s not invent blockers for Henriks’ work here.<br>
<br>
<mini-rant>I don’t quite understand the opposition against unifying the assertion styles and test suite/ runner API surface. Why insist on keeping this separation whereas it’s all written in JS and can be the same with a bit of effort? Same goes for the Python counterpart, of course; let’s get the API surface unified at the very least!</mini-rant><br></blockquote><div><br></div><div>You are preaching to the choir. When I was on the Firefox team, I found the N variations for writing tests to be maddening. The variation adds significant cognitive overhead. My personal experience is that unless the underlying code being tested is in a more verbose language (C, C++, Java) or has significant complexity, it takes longer to write tests than the code itself (often 2-3x more time). But with Firefox features, I found that test writing consumed a disproportional amount of time when compared to my experience writing similar code that wasn't for Firefox. And I chalk a lot of this up to the complexity of writing tests for Firefox and the lack of a unified, well-polished set of tools and standards. I view the inconsistent testing "APIs" used by Firefox a massive source of technical debt and an ongoing burden on developer productivity. How or who fixes that, I'm not sure. Furthermore, the last developer productivity survey showed that people think debugging [intermittent] test failures and things like Try times to be the most important item w.r.t. test running. So that's where the focus of the productivity team currently is. I'd love for someone to take ownership of unifying the test "APIs."<br></div></div><br></div></div>