RW repository general questions - issues

[Lukáš Fryč]

On Mon, Nov 4, 2013 at 9:24 PM, Brian Leathem <bleathem at gmail.com> wrote:

> 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.
>

Note that developers are responsible for running tests in default mode,
which means in PhantomJS.
If test pass on PhantomJS but breaks on Chrome/Firefox, then you should
look into resolving portability of the test.
You can definitely file an issue if the fix isn't obvious.


>
> > *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.
>

Karma supports junit reporter - JUnit's XML report could be better place
where to store details of failure.
I'm not sure how it would play together though.


>
> > *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.
>

widget-test-base could be used this way


>
> > *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
> _______________________________________________
> richfaces-dev mailing list
> richfaces-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/richfaces-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/richfaces-dev/attachments/20131104/0ddcc57d/attachment-0001.html