-
1. Re: RW repository general questions - issues
1 of 1 people found this helpfulComments inline
1. Building RW repo: No provider for "framework:jasmine"! , I had to run it with --force
-> issue tracker
2. I am wondering whether it is not viable to extract testing info from CONTRIBUTION.md (https://github.com/richwidgets/richwidgets/blob/master/CONTRIBUTING.md) into something like TESTING.md
-> already done in upstream
3. CONTRIBUTION.md (https://github.com/richwidgets/richwidgets/blob/master/CONTRIBUTING.md) is IMHO missing some info about contributing process: e.g. file a issue, file PR etc., also some general encouragement for contributing. Actually I would rename CONTRIBUTION.md (https://github.com/richwidgets/richwidgets/blob/master/CONTRIBUTING.md) to TESTING.md and create new CONTRIBUTION.md
-> you are right, please submit an issue
4. We are using Karma. Should not be there command to install it, like it is for all the required tools ?
-> yes, one should intall grunt-cli and karma in order to use
instructions correctly (you may use `grunt test` without installing
karma though)
5. We are IMHO missing a process for testing the WIDGETS. I am aware that we are creating it continually. I just wanted to point it out, that we should define some rules.
-> good point, let's create an issue for testing conventions and
brainstorm that at knowledge share at Thursday
_______________________________________________
richfaces-dev mailing list
https://lists.jboss.org/mailman/listinfo/richfaces-dev
-
2. Re: RW repository general questions - issues
Thanks Lukas for answers,
I submitted following issues/pull requests:
1. https://github.com/richwidgets/richwidgets/issues/64
3. https://github.com/richwidgets/richwidgets/issues/70
4. https://github.com/richwidgets/richwidgets/pull/69
-
3. Re: RW repository general questions - issues
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. 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 ?
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.
1.3 There are also testing cross browser issues. E.g. on test fails on Firefox, but it passes on Chrome. The difference is subtle: Attribute 'style': expected value 'height: 1px; display: none;' instead of 'height: 0px; display: none;'; which will be hard to maintain.
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.
2.2 Have you considered using jasmine.async ? Using of it makes waits methods redundant imho. Here is nice blog about it.
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.
I would like to ask you again for your insight, which of the above deserves issues submitting ?
-
4. Re: RW repository general questions - issues
On 13-10-29 02:42 AM, Lukas Fryc wrote:
>> 4. We are using Karma. Should not be there command to install it, like it is for all the required tools ?
-> yes, one should intall grunt-cli and karma in order to use instructions correctly (you may use `grunt test` without installing karma though)
We should standaridze our docs and approach on using "grunt test". This
involves the least amount of hassle on the users' part to get going.
Brian
_______________________________________________
richfaces-dev mailing list
https://lists.jboss.org/mailman/listinfo/richfaces-dev
-
5. Re: RW repository general questions - issues
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
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
https://lists.jboss.org/mailman/listinfo/richfaces-dev
-
6. Re: RW repository general questions - issues
On Mon, Nov 4, 2013 at 9:24 PM, Brian Leathem <bleathem@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
(
)
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
https://lists.jboss.org/mailman/listinfo/richfaces-dev