RW repository general questions - issues

[Brian Leathem]

On Fri 01 Nov 2013 11:40:10 AM PDT, Juraj Húska wrote:
>
> Round 2.
>
> *1.* *DOM testing*
> *1.1* First thing, currently it can just tell me that something 
> changed. But with my knowledge I can not say whether it is a bug or 
> just some component upgrade (bootstrap, ...). Therefore I am wondering 
> whether you have some big plans with it ? I am also quite afraid of 
> maintainability of such tests. 

I agree that DOM testing is fragile.  We should use it sparingly - test 
that widgets are created/destroyed as expected.  DOM testing should not 
be used for asserting state.

> Should I file an issue when such test fails, or should I just correct 
> the test when I think that it is not a bug ?  What kind of changes do 
> you things in general are bugs ?

Definitely file an issue.  Devs should run and fix tests after making 
breaking changes.  Any breakages found by CI or QA should be anomolous.

> *1.2* Secondly, when such test fails, it pollutes the log with whole 
> dom of the expected and actual results. It makes other tests quite 
> unreadable. Proposition: play with logging features (preffered), or 
> make the DOM testing separate from the normal jasmine tests.

On the one hand, the summary message at the end is not verbose enough to 
fully identify the error, yet OTOH, the full DOM listing is too long to 
locate the source of the error.  Any improvements that can be made here 
would be greatly appreciated.  I don't think it's worth filing an issue 
unless we have some concrete ideas of how we can improve this.

> *2.* *Jasmine Waitings*
> *2.1.* Should not we somehow abstract the timeout which is set to the 
> waitings methods ? Have we already encountered some differences 
> between local and CI test execution ? I am for some kind of ancestor 
> of all tests, which would define e.g. timeout constants and other.

A global object containing "constants" as properties would also work.  
Please file an issue.

> *2.2* Have you considered using jasmine.async ? Using of it makes 
> +waits+ methods redundant imho. Here 
> (http://www.htmlgoodies.com/html5/javascript/using-the-done-method-in-your-jasmine-driven-asynchronous-javascript-tests.html#fbid=HZXW8goGfwg) 
> is nice blog about it.

Having read thorugh that blog, I don't see how the jamine.async approach 
is any more readable.  What would be useful would be to see a rewrite of 
one of the RichWidget aync tests using this API so we could make a 
meaningful comparison.  Do you want to try that Juraj? Let's explore 
this in this developer forum rather than filing an issue (yet).

> *3. Tests reusability*
> *3.1.* I have already mentioned common ancestor for tests. Do you 
> think that it is feasible in JS in a nice way ? I think that for 
> example testing of callbacks can be somehow abstracted and thus tests 
> will be a little bit DRYer.
> *3.2* What about introducing Page Fragments into the tests ? For 
> example selecting of an +pickList+ item requires following:
> item.trigger('mousedown');
> item.trigger('mouseup');
> Similar things can be nicely encapsulated IMHO.

This is something we should definitely keep in mind.  However also 
consider that these user interaction tests are also encapuslated within 
the interaction tests of a widget.  We should start by creating helper 
functions for these tests where required, and we can refactor those out 
to Page Fragments if it proves beneficial to do so.

Brian