6 Replies Latest reply on Nov 4, 2013 3:39 PM by

    RW repository general questions - issues

    Juraj Húska Master

      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 into something like TESTING.md
      3. CONTRIBUTION.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 to TESTING.md and create new CONTRIBUTION.md
      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

       

        • 1. Re: RW repository general questions - issues
          Lukáš Fryč Master

          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

           

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

          richfaces-dev@lists.jboss.org

          https://lists.jboss.org/mailman/listinfo/richfaces-dev

           

          1 of 1 people found this helpful
          • 3. Re: RW repository general questions - issues
            Juraj Húska Master

            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
              Brian Leathem Master

              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

              richfaces-dev@lists.jboss.org

              https://lists.jboss.org/mailman/listinfo/richfaces-dev

               

              • 5. Re: RW repository general questions - issues
                Brian Leathem Master

                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

                _______________________________________________

                richfaces-dev mailing list

                richfaces-dev@lists.jboss.org

                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

                  (

                  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@lists.jboss.org

                  https://lists.jboss.org/mailman/listinfo/richfaces-dev