<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 4, 2013 at 9:24 PM, Brian Leathem <span dir="ltr"><<a href="mailto:bleathem@gmail.com" target="_blank">bleathem@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Fri 01 Nov 2013 11:40:10 AM PDT, Juraj Húska wrote:<br>
><br>
> Round 2.<br>
><br>
> *1.* *DOM testing*<br>
> *1.1* First thing, currently it can just tell me that something<br>
> changed. But with my knowledge I can not say whether it is a bug or<br>
> just some component upgrade (bootstrap, ...). Therefore I am wondering<br>
> whether you have some big plans with it ? I am also quite afraid of<br>
> maintainability of such tests.<br>
<br>
</div>I agree that DOM testing is fragile. We should use it sparingly - test<br>
that widgets are created/destroyed as expected. DOM testing should not<br>
be used for asserting state.<br>
<div class="im"><br>
> Should I file an issue when such test fails, or should I just correct<br>
> the test when I think that it is not a bug ? What kind of changes do<br>
> you things in general are bugs ?<br>
<br>
</div>Definitely file an issue. Devs should run and fix tests after making<br>
breaking changes. Any breakages found by CI or QA should be anomolous.<br></blockquote><div><br></div><div>Note that developers are responsible for running tests in default mode, which means in PhantomJS.</div><div>If test pass on PhantomJS but breaks on Chrome/Firefox, then you should look into resolving portability of the test.</div>
<div>You can definitely file an issue if the fix isn't obvious.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> *1.2* Secondly, when such test fails, it pollutes the log with whole<br>
> dom of the expected and actual results. It makes other tests quite<br>
> unreadable. Proposition: play with logging features (preffered), or<br>
> make the DOM testing separate from the normal jasmine tests.<br>
<br>
</div>On the one hand, the summary message at the end is not verbose enough to<br>
fully identify the error, yet OTOH, the full DOM listing is too long to<br>
locate the source of the error. Any improvements that can be made here<br>
would be greatly appreciated. I don't think it's worth filing an issue<br>
unless we have some concrete ideas of how we can improve this.<br></blockquote><div><br></div><div>Karma supports junit reporter - JUnit's XML report could be better place where to store details of failure.</div><div>
I'm not sure how it would play together though.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> *2.* *Jasmine Waitings*<br>
> *2.1.* Should not we somehow abstract the timeout which is set to the<br>
> waitings methods ? Have we already encountered some differences<br>
> between local and CI test execution ? I am for some kind of ancestor<br>
> of all tests, which would define e.g. timeout constants and other.<br>
<br>
</div>A global object containing "constants" as properties would also work.<br>
Please file an issue.<br></blockquote><div><br></div><div>widget-test-base could be used this way</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> *2.2* Have you considered using jasmine.async ? Using of it makes<br>
> +waits+ methods redundant imho. Here<br>
> (<a href="http://www.htmlgoodies.com/html5/javascript/using-the-done-method-in-your-jasmine-driven-asynchronous-javascript-tests.html#fbid=HZXW8goGfwg" target="_blank">http://www.htmlgoodies.com/html5/javascript/using-the-done-method-in-your-jasmine-driven-asynchronous-javascript-tests.html#fbid=HZXW8goGfwg</a>)<br>
> is nice blog about it.<br>
<br>
</div>Having read thorugh that blog, I don't see how the jamine.async approach<br>
is any more readable. What would be useful would be to see a rewrite of<br>
one of the RichWidget aync tests using this API so we could make a<br>
meaningful comparison. Do you want to try that Juraj? Let's explore<br>
this in this developer forum rather than filing an issue (yet).<br>
<div class="im"><br>
> *3. Tests reusability*<br>
> *3.1.* I have already mentioned common ancestor for tests. Do you<br>
> think that it is feasible in JS in a nice way ? I think that for<br>
> example testing of callbacks can be somehow abstracted and thus tests<br>
> will be a little bit DRYer.<br>
> *3.2* What about introducing Page Fragments into the tests ? For<br>
> example selecting of an +pickList+ item requires following:<br>
> item.trigger('mousedown');<br>
> item.trigger('mouseup');<br>
> Similar things can be nicely encapsulated IMHO.<br>
<br>
</div>This is something we should definitely keep in mind. However also<br>
consider that these user interaction tests are also encapuslated within<br>
the interaction tests of a widget. We should start by creating helper<br>
functions for these tests where required, and we can refactor those out<br>
to Page Fragments if it proves beneficial to do so.<br>
<span class="HOEnZb"><font color="#888888"><br>
Brian<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
richfaces-dev mailing list<br>
<a href="mailto:richfaces-dev@lists.jboss.org">richfaces-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/richfaces-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/richfaces-dev</a></div></div></blockquote></div><br></div></div>