<div dir="ltr">Yes this is a good idea too, Geoff Brown is actually working on it already in bug 1357520, though it won't be with rr (at least to start). Afaik, there are still issues with running rr in AWS, we'd need to run tasks in DO instead and there's probably some can of worms there. But rr is very much on the radar (just ask jmaher about it).<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 7, 2017 at 5:34 PM, Mike Conley <span dir="ltr"><<a href="mailto:mconley@mozilla.com" target="_blank">mconley@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I know you asked for linting ideas, and I don't think this qualifies (so<br>
feel free to ignore), but just in case...<br>
<br>
roc wrote this Chaos Mode thing:<br>
<a href="http://robert.ocallahan.org/2014/03/introducing-chaos-mode.html" rel="noreferrer" target="_blank">http://robert.ocallahan.org/<wbr>2014/03/introducing-chaos-<wbr>mode.html</a><br>
<br>
I remember wondering idly a year or so back with wlach (and maybe you?)<br>
whether or not new tests should have a "proving ground", where before<br>
being approved for landing in automation, they have to do a number of<br>
rounds on try with chaos mode turned on to shake out non-determinism /<br>
races.<br>
<br>
Or, perhaps less ham-fistedly, maybe we should make it possible to run<br>
one or more tests on try in chaos mode via try syntax, so that people<br>
can try them out before landing.<br>
<br>
-Mike<br>
<span class=""><br>
On 2017-07-06 2:47 PM, Andrew Halberstadt wrote:<br>
> I'm looking into creating custom eslint rules that aim to avoid common<br>
> causes of oranges in tests. We have an MDN page<br>
</span>> <<a href="https://developer.mozilla.org/en-US/docs/Mozilla/QA/Avoiding_intermittent_oranges" rel="noreferrer" target="_blank">https://developer.mozilla.<wbr>org/en-US/docs/Mozilla/QA/<wbr>Avoiding_intermittent_oranges</a>><br>
<span class="">> containing some of these already. Some of those patterns might be pretty<br>
> hard to catch with a linter, but others look do-able. So far, I'm<br>
> thinking of adding rules for:<br>
><br>
</span><span class="">>   * No arbitrary setTimeouts<br>
>   * No synthesizeKey without waiting for focus<br>
>   * No deleting original tab<br>
</span>>   * ???<br>
<span class="">><br>
> These rules would only be configured to run on test files. I have a few<br>
> questions:<br>
><br>
</span>>  1. Would this cause too much of a burden for legitimate uses of those<br>
>     patterns?<br>
>  2. Do any of the other patterns on that page look feasible to implement<br>
>     as linters?<br>
>  3. Are there additional things not listed on that page that we could<br>
<span class="im HOEnZb">>     lint for?<br>
><br>
> I'd love to find volunteer(s) who are more familiar with writing<br>
> mochitests than myself (and who also care about this issue) to help<br>
> brainstorm and provide more in-depth feedback. I want to strike a<br>
> balance between preventing oranges and not over-burdening test authors,<br>
> but I'm not sure what that balance looks like.<br>
><br>
> Thanks in advance for your input,<br>
> Andrew<br>
><br>
><br>
</span><div class="HOEnZb"><div class="h5">> ______________________________<wbr>_________________<br>
> firefox-dev mailing list<br>
> <a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a><br>
> <a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/<wbr>listinfo/firefox-dev</a><br>
><br>
______________________________<wbr>_________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/<wbr>listinfo/firefox-dev</a><br>
</div></div></blockquote></div><br></div>