<div dir="ltr"><div>It really saddens me how very few engineers seem to care about browser tests. Our browser tests are failing all over the place. I just saw this bug [1] which has been sitting around for ages and denying us green tests in Echo one of our most important features.</div><div><br></div><div>How can we change this anti-pattern?</div><div><br></div><div>Dan Duval, would it make sense to do a survey as you did with Vagrant to understand how our developers think of these? Such as who owns them... who is responsible for a test failing... who writes them... who doesn't understand them.. why they don't understand them etc...?</div><div><br></div><div>[1] <a href="https://phabricator.wikimedia.org/T72298">https://phabricator.wikimedia.org/T72298</a></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 26, 2015 at 5:54 PM, Dan Duvall <span dir="ltr"><<a href="mailto:dduvall@wikimedia.org" target="_blank">dduvall@wikimedia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On Thu, Mar 26, 2015 at 3:38 PM, Jon Robson <<a href="mailto:jdlrobson@gmail.com">jdlrobson@gmail.com</a>> wrote:<br>
> The lack of replies from any mobile team members seems to suggest I'm the<br>
> only one watching this. In that case I'd rather we split up the big<br>
> MobileFrontend job into various jobs based on certain features. How can we<br>
> get more people caring about browser tests? Naming and shaming?<br>
<br>
</span>We have a couple projects in the works that will hopefully help.[1][2]<br>
They don't go so far as to name and shame (we'll leave that up to you<br>
:), but they should promote more ownership over browser tests, better<br>
communication of failure, and analysis of failure over time and by<br>
test function (feature vs smoke vs regression).<br>
<br>
If many of these browser tests are serving as regression/smoke tests,<br>
it might be worthwhile to not only separate them out, but to remove<br>
some of the layers of abstraction to make tests more maintainable. I<br>
often try to think about tests in terms of a value-to-debt ratio (i.e.<br>
"How likely is it that I'll have to fix or refactor this test down the<br>
road and is it worth it?") and, while I find quite a bit of value in<br>
Cucumber for the sake of acceptance(-esque) testing (it keeps me<br>
mindful of the UX),[3] it introduces quite a bit of debt in its layers<br>
of abstraction and indirection (it's always a red flag when you have<br>
to grep to find your test implementation). Even its creators believe<br>
the value of Cucumber lies in its collaboration/planning capacities,<br>
not in its function as a test runner.[4]<br>
<br>
It's entirely possible, as of the 1.0.0 release, to use MW-Selenium<br>
without Cucumber, so perhaps we could experiment with simple RSpec<br>
examples for these types of tests.<br>
<br>
Tooling aside, there are broader discussions that need to take place<br>
among those that are practicing or have practiced TDD/BDD in the<br>
organization and how we might (or might not) promote theses practices<br>
among others. I'll be trying to form such a group next quarter (will<br>
it be a 'guild'?, a 'league'?, no need for tough decisions just<br>
yet[5]), so let's maintain a dialogue on that front if you're<br>
interested and willing.<br>
<br>
[1] <a href="https://phabricator.wikimedia.org/T88706" target="_blank">https://phabricator.wikimedia.org/T88706</a><br>
[2] <a href="https://phabricator.wikimedia.org/T89375" target="_blank">https://phabricator.wikimedia.org/T89375</a><br>
[3] <a href="https://gerrit.wikimedia.org/r/#/c/196492/10/features/role_settings.feature" target="_blank">https://gerrit.wikimedia.org/r/#/c/196492/10/features/role_settings.feature</a><br>
[4] <a href="https://cukes.info/blog/2014/03/03/the-worlds-most-misunderstood-collaboration-tool" target="_blank">https://cukes.info/blog/2014/03/03/the-worlds-most-misunderstood-collaboration-tool</a><br>
[5] <a href="https://www.youtube.com/watch?v=6KSiyaqnZYs" target="_blank">https://www.youtube.com/watch?v=6KSiyaqnZYs</a><br>
<span class=""><br>
> Practically, the current big job [1] we have has far too many false<br>
> positives and it is just noise to me. I was paying attention to the smoke<br>
> tests [2] but I was told that was an upstream bug and haven't been watching<br>
> it since. Any idea why that has been failing recently? Nothing has broken<br>
> here...<br>
><br>
> [1]<br>
> <a href="https://integration.wikimedia.org/ci/view/Mobile/job/browsertests-MobileFrontend-en.m.wikipedia.beta.wmflabs.org-linux-chrome-sauce/" target="_blank">https://integration.wikimedia.org/ci/view/Mobile/job/browsertests-MobileFrontend-en.m.wikipedia.beta.wmflabs.org-linux-chrome-sauce/</a><br>
> [2]<br>
> <a href="https://integration.wikimedia.org/ci/view/Mobile/job/browsertests-MobileFrontend-SmokeTests-linux-chrome-sauce/" target="_blank">https://integration.wikimedia.org/ci/view/Mobile/job/browsertests-MobileFrontend-SmokeTests-linux-chrome-sauce/</a><br>
><br>
<br>
</span>Have you tried to reproduce these failures by executing the tests<br>
locally, against either Beta or your local MW? I'll be in the office<br>
tomorrow if you want advice on how to best go about it.<br>
<span class=""><font color="#888888"><br>
Dan<br>
<br>
--<br>
Dan Duvall<br>
Automation Engineer<br>
Wikimedia Foundation<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Jon Robson<br>* <a href="http://jonrobson.me.uk" target="_blank">http://jonrobson.me.uk</a><br>* <a href="https://www.facebook.com/jonrobson" target="_blank">https://www.facebook.com/jonrobson</a><br>* @rakugojon<br></div>
</div></div>