<div dir="ltr">Apologies for spam if you are already aware of this, but I have proposed two workshops for this years' hackathons, write the first browsertests/Selenium test[0] and Fix broken browsertests/Selenium Jenkins jobs[1].<br><br>Željko<br><div>--</div><div>0: <a href="https://phabricator.wikimedia.org/T94024">https://phabricator.wikimedia.org/T94024</a><br>1: <a href="https://phabricator.wikimedia.org/T94299">https://phabricator.wikimedia.org/T94299</a><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 14, 2015 at 8:55 PM, Tomasz Finc <span dir="ltr"><<a href="mailto:tfinc@wikimedia.org" target="_blank">tfinc@wikimedia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">CC'ing Stephane from the Collaboration team who's keenly interested in<br>
this as well.<br>
<span class="HOEnZb"><font color="#888888"><br>
--tomasz<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Fri, Apr 3, 2015 at 2:30 AM, Joaquin Oltra Hernandez<br>
<<a href="mailto:jhernandez@wikimedia.org">jhernandez@wikimedia.org</a>> wrote:<br>
> Personally, I love them, but more often than not when I run them a few<br>
> things happen that make me sad:<br>
><br>
> Tests take too long to run<br>
><br>
> Even on Gather, which doesn't have too many tests, it takes a really long<br>
> time, which discourages running all tests every time.<br>
><br>
> Tests don't block jenkins merges<br>
><br>
> This would be key for me. Do this. Block jenkins. Then we'll be forced to<br>
> make it faster, make better browser tests, and everybody will have to care<br>
> because they will run and block merges.<br>
><br>
> So there's a few key items that I would love to see:<br>
><br>
> Improve performance (needs magnitudes improvements, a lot of work on<br>
> different fronts)<br>
> Fully support headless browsers like phantom (they randomly break with<br>
> timeout errors and other problems, but are the faster/painless ways of<br>
> running the tests)<br>
> Run the browser tests (or a smoke subset) on jenkins patches as a voting<br>
> job. Crucial for making everybody care about the tests and to stop<br>
> regressions.<br>
><br>
><br>
> On Thu, Apr 2, 2015 at 10:18 PM, Jon Robson <<a href="mailto:jdlrobson@gmail.com">jdlrobson@gmail.com</a>> wrote:<br>
>><br>
>> Personally, I think one team needs to get this completely right and<br>
>> demonstrate the difference e.g. fewer bugs, iterating fast, quicker<br>
>> code review time etc..<br>
>><br>
>> Talks can come off the back of that.<br>
>> The majority of people I speak to seem to advocate a TDD approach but<br>
>> I think we don't make life easy enough for them to do that and we lack<br>
>> the discipline to do that. We need to work on both of those two.<br>
>><br>
>> I'm confident if we do a survey we'll identify and prioritise the pain<br>
>> points. For me my top priority would be getting the infrastructure in<br>
>> place on all our existing codebases in a consistent way that make<br>
>> adding tests effortless and prevent code merging when it breaks those<br>
>> tests but there may be more important things we need to sort out<br>
>> first!<br>
>><br>
>><br>
>> On Tue, Mar 31, 2015 at 1:16 AM, Sam Smith <<a href="mailto:samsmith@wikimedia.org">samsmith@wikimedia.org</a>> wrote:<br>
>> > Dan, Jon,<br>
>> ><br>
>> > I got caught up in meetings yesterday – you'll see this email a lot<br>
>> > during<br>
>> > Q4 ;) – so I delayed sending this email, so forgive the repetitions of<br>
>> > some<br>
>> > of Dan's points/questions:<br>
>> ><br>
>> >> Here are a few ways I can think of:<br>
>> >><br>
>> >> include feedback on browser tests – or lack thereof – during code<br>
>> >> review<br>
>> >><br>
>> >> make browser test failures even more visible than they currently are –<br>
>> >> but<br>
>> >> maybe not the success reports, eh?<br>
>> >><br>
>> >> can these reports be made to point at a bunch of candidate changes that<br>
>> >> may have broken 'em?<br>
>> >><br>
>> >> hold a browser-test-athon with the team and any volunteers at the<br>
>> >> {Lyon,Wikimania} hackathon<br>
>> >><br>
>> >> make it trivial to run 'em, if it isn't already<br>
>> ><br>
>> > From what little experience I have of trying to establish team<br>
>> > practices,<br>
>> > I'd say that it's best to advocate for <practice> and demonstrate its<br>
>> > value*, rather than criticise. I'd love to see you funnel your passion<br>
>> > for<br>
>> > browser testing into a talk or series of talks for the mobile team – the<br>
>> > org, maybe? – or maybe you've got some recommended reading or talks<br>
>> > you'd<br>
>> > like to share that'll inspire.<br>
>> ><br>
>> > –Sam<br>
>> ><br>
>> > * If you'd like to hear my opinions about browser testing, then insert<br>
>> > one<br>
>> > beer and wind me up a little<br>
>> ><br>
>> ><br>
>> > On Mon, Mar 30, 2015 at 8:47 PM, Dan Duvall <<a href="mailto:dduvall@wikimedia.org">dduvall@wikimedia.org</a>><br>
>> > wrote:<br>
>> >><br>
>> >> <a href="https://phabricator.wikimedia.org/T94472" target="_blank">https://phabricator.wikimedia.org/T94472</a><br>
>> >><br>
>> >> On Mon, Mar 30, 2015 at 12:39 PM, Dan Duvall <<a href="mailto:dduvall@wikimedia.org">dduvall@wikimedia.org</a>><br>
>> >> wrote:<br>
>> >> > On Mon, Mar 30, 2015 at 10:30 AM, Jon Robson <<a href="mailto:jdlrobson@gmail.com">jdlrobson@gmail.com</a>><br>
>> >> > wrote:<br>
>> >> >> It really saddens me how very few engineers seem to care about<br>
>> >> >> browser<br>
>> >> >> tests. Our browser tests are failing all over the place. I just saw<br>
>> >> >> this bug<br>
>> >> >> [1] which has been sitting around for ages and denying us green<br>
>> >> >> tests<br>
>> >> >> in<br>
>> >> >> Echo one of our most important features.<br>
>> >> >><br>
>> >> >> How can we change this anti-pattern?<br>
>> >> ><br>
>> >> > That's exactly what I'd like to explore with you and other like<br>
>> >> > minds.<br>
>> >> ><br>
>> >> >> Dan Duval, would it make sense to do a survey as you did with<br>
>> >> >> Vagrant<br>
>> >> >> to<br>
>> >> >> understand how our developers think of these? Such as who owns<br>
>> >> >> them...<br>
>> >> >> who<br>
>> >> >> is responsible for a test failing... who writes them... who doesn't<br>
>> >> >> understand them.. why they don't understand them etc...?<br>
>> >> ><br>
>> >> > Great idea! I suspect that the number of false positives in a given<br>
>> >> > repo's test suite is inversely related to the number of developers on<br>
>> >> > the team actually writing tests, and the affordance by managers to do<br>
>> >> > so. If you're not regularly writing tests, you're probably not going<br>
>> >> > to feel comfortable troubleshooting and refactoring someone else's.<br>
>> >> > If<br>
>> >> > TDD isn't factored in to your team's velocity, you may feel like the<br>
>> >> > investment in writing tests (or learning to write them) isn't worth<br>
>> >> > it<br>
>> >> > or comes at the risk of missing deadlines.<br>
>> >> ><br>
>> >> > A survey could definitely help us to verify (or disprove) these<br>
>> >> > relationships.<br>
>> >> ><br>
>> >> > Some other questions I can think of:<br>
>> >> ><br>
>> >> >  - How valuable are unit tests to the health/quality of a software<br>
>> >> > project?<br>
>> >> >  - How valuable are browser tests to the health/quality of a software<br>
>> >> > project?<br>
>> >> >  - How much experience do you have with TDD?<br>
>> >> >  - Would you like more time to learn or practice TDD?<br>
>> >> >  - How often do you write tests when developing a new feature?<br>
>> >> >    - What kinds of test? (% of unit test vs. browser test)<br>
>> >> >  - How often do you write tests to verify a bugfix?<br>
>> >> >    - What kinds of test? (% of unit test vs. browser test)<br>
>> >> >  - When would you typically write a unit test? (before<br>
>> >> > implementation,<br>
>> >> > after implementation, when stuff breaks)<br>
>> >> >  - When would you typically write a browser test? (during conception,<br>
>> >> > before implementation, after implementation, when stuff breaks)<br>
>> >> >  - What are the largest barriers to writing/running unit tests? (test<br>
>> >> > framework, documentation/examples, execution time, CI, structure of<br>
>> >> > my<br>
>> >> > code, structure of code I depend on)<br>
>> >> >  - What are the largest barriers to writing/running browser tests?<br>
>> >> > (test framework, documentation/examples, execution time, CI)<br>
>> >> >  - What are the largest barriers to debugging test failure? (test<br>
>> >> > framework, confusing errors/stack traces, documentation/examples,<br>
>> >> > debugging tools)<br>
>> >> ><br>
>> >> > I'll create a Phab task to track it. :)<br>
>> >> ><br>
>> >> > --<br>
>> >> > Dan Duvall<br>
>> >> > Automation Engineer<br>
>> >> > Wikimedia Foundation<br>
>> >><br>
>> >><br>
>> >><br>
>> >> --<br>
>> >> Dan Duvall<br>
>> >> Automation Engineer<br>
>> >> Wikimedia Foundation<br>
>> >><br>
>> >> _______________________________________________<br>
>> >> Mobile-l mailing list<br>
>> >> <a href="mailto:Mobile-l@lists.wikimedia.org">Mobile-l@lists.wikimedia.org</a><br>
>> >> <a href="https://lists.wikimedia.org/mailman/listinfo/mobile-l" target="_blank">https://lists.wikimedia.org/mailman/listinfo/mobile-l</a><br>
>> ><br>
>> ><br>
>><br>
>><br>
>><br>
>> --<br>
>> 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>
>><br>
>> _______________________________________________<br>
>> Mobile-l mailing list<br>
>> <a href="mailto:Mobile-l@lists.wikimedia.org">Mobile-l@lists.wikimedia.org</a><br>
>> <a href="https://lists.wikimedia.org/mailman/listinfo/mobile-l" target="_blank">https://lists.wikimedia.org/mailman/listinfo/mobile-l</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Mobile-l mailing list<br>
> <a href="mailto:Mobile-l@lists.wikimedia.org">Mobile-l@lists.wikimedia.org</a><br>
> <a href="https://lists.wikimedia.org/mailman/listinfo/mobile-l" target="_blank">https://lists.wikimedia.org/mailman/listinfo/mobile-l</a><br>
><br>
<br>
</div></div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
QA mailing list<br>
<a href="mailto:QA@lists.wikimedia.org">QA@lists.wikimedia.org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/qa" target="_blank">https://lists.wikimedia.org/mailman/listinfo/qa</a><br>
</div></div></blockquote></div><br></div>