12:23 a.m.
Hello all,
I have encounter following issues during working with RW repository. Could you please tell
me which ones deserves an issue in the GitHub issue tracker ?
1. Building RW repo: No provider for "framework:jasmine"! , I had to run it with
--force
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
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 {emoticon:class=jive_macro
jive_emote|src=https://community.jboss.org/6.0.3.60ddddd/images/emoticons...
4. We are using Karma. Should not be there command to install it, like it is for all the
required tools ?
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.
Cheers
Juro
Posted by forums
Original post: https://community.jboss.org/message/843557#843557
4:42 a.m.
Comments 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 {emoticon:class=jive_macro
jive_emote|src=https://community.jboss.org/6.0.3.60ddddd/images/emoticons...
-> 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
12:26 a.m.
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
5. https://github.com/richwidgets/richwidgets/issues/67
Posted by forums
Original post: https://community.jboss.org/message/843750#843750
9:40 a.m.
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.
*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
(http://www.htmlgoodies.com/html5/javascript/using-the-done-method-in-your...)
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 ?
Posted by forums
Original post: https://community.jboss.org/message/844145#844145
2:24 p.m.
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...)
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
2:39 p.m.
On Mon, Nov 4, 2013 at 9:24 PM, Brian Leathem <bleathem(a)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...
)
> 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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/richfaces-dev
1:58 p.m.
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
4533
days inactive
4539
days old
6 comments
4 participants
participants (4)
-
Brian Leathem -
Juraj Húska -
Lukas Fryc -
Lukáš Fryč