Re: [xwiki-devs] [xwiki-notifications] r28950 - platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table
----- "Denis Gervalle" <[email protected]> wrote:
On Thu, May 20, 2010 at 19:23, Vincent Massol <[email protected]> wrote:
On May 20, 2010, at 7:15 PM, dgervalle (SVN) wrote:
Author: dgervalle Date: 2010-05-20 19:15:53 +0200 (Thu, 20 May 2010) New Revision: 28950
Modified:
platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table/livetable.js
Log: XWIKI-5212 - Livetable filter serialization does not properly support multi-valued form elements Merge from trunk r28947
Do we have a test for this? How do we unit-test UI components?
This would be nice to have. Building proper tests is not so easy, this could be very long to setup, since you need to test in several browsers and you need full AJAX interaction.
That's basically what we do with Selenium, except that we test the integration of the features in the wiki, not the atomic behaviors of the components. There isn't really an alternative to launching a browser for testing our JS components, since most if not all of them heavily rely on a DOM, so just a JS runtime will not be enough. We could envisage a JS unit-testing system like this : - Write tests in .js files, using JSUnit or any other unit testing JS framework (http://ejohn.org/blog/which-unit-testing-framework/) - Slurp the tests in a XAR using a maven plugin - Execute the tests inside XE, using Selenium wdyt ? Jerome.
I am not used to such automated testing, but I am not sure the investment is worse the improvement we could get from them.
On the other side, I use livetables JS heavily, so you could be assured that my fixes/improvements are either well tested or will be fixed ASAP since all changes I introduce is already in production. We also usually test them on all supported browsers, and at least on IE6/7/8, FF3 (Win/Mac), Safari4 (Mac) and Chrome (Mac) FYI, I found this one when we have introduced the usage of hashes to provide "Back to the list" links. I will soon commit an improvement supporting the page size in hash as well, so you can really get very precise "back to the list" return links.
Denis
Thanks
-Vincent
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 05/21/2010 12:32 PM, Jerome Velociter wrote:
----- "Denis Gervalle"<[email protected]> wrote:
On Thu, May 20, 2010 at 19:23, Vincent Massol<[email protected]> wrote:
On May 20, 2010, at 7:15 PM, dgervalle (SVN) wrote:
Author: dgervalle Date: 2010-05-20 19:15:53 +0200 (Thu, 20 May 2010) New Revision: 28950
Modified:
platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table/livetable.js
Log: XWIKI-5212 - Livetable filter serialization does not properly support multi-valued form elements Merge from trunk r28947
Do we have a test for this? How do we unit-test UI components?
This would be nice to have. Building proper tests is not so easy, this could be very long to setup, since you need to test in several browsers and you need full AJAX interaction.
That's basically what we do with Selenium, except that we test the integration of the features in the wiki, not the atomic behaviors of the components.
There isn't really an alternative to launching a browser for testing our JS components, since most if not all of them heavily rely on a DOM, so just a JS runtime will not be enough.
We could envisage a JS unit-testing system like this :
- Write tests in .js files, using JSUnit or any other unit testing JS framework (http://ejohn.org/blog/which-unit-testing-framework/) - Slurp the tests in a XAR using a maven plugin - Execute the tests inside XE, using Selenium
wdyt ?
Another alternative I investigated was to use JSUnit with an injected DOM, from a HTML file placed in src/test/resources. I had a PoC with this at one point, and it was working fine. I'll try to find it.
Jerome.
I am not used to such automated testing, but I am not sure the investment is worse the improvement we could get from them.
On the other side, I use livetables JS heavily, so you could be assured that my fixes/improvements are either well tested or will be fixed ASAP since all changes I introduce is already in production. We also usually test them on all supported browsers, and at least on IE6/7/8, FF3 (Win/Mac), Safari4 (Mac) and Chrome (Mac) FYI, I found this one when we have introduced the usage of hashes to provide "Back to the list" links. I will soon commit an improvement supporting the page size in hash as well, so you can really get very precise "back to the list" return links.
Denis
Thanks
-Vincent
-- Sergiu Dumitriu http://purl.org/net/sergiu/
On Fri, May 21, 2010 at 12:32, Jerome Velociter <[email protected]> wrote:
----- "Denis Gervalle" <[email protected]> wrote:
On Thu, May 20, 2010 at 19:23, Vincent Massol <[email protected]> wrote:
On May 20, 2010, at 7:15 PM, dgervalle (SVN) wrote:
Author: dgervalle Date: 2010-05-20 19:15:53 +0200 (Thu, 20 May 2010) New Revision: 28950
Modified:
platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table/livetable.js
Log: XWIKI-5212 - Livetable filter serialization does not properly support multi-valued form elements Merge from trunk r28947
Do we have a test for this? How do we unit-test UI components?
This would be nice to have. Building proper tests is not so easy, this could be very long to setup, since you need to test in several browsers and you need full AJAX interaction.
That's basically what we do with Selenium, except that we test the integration of the features in the wiki, not the atomic behaviors of the components.
Yes, and there is a selenium test regarding AllDocs that obviously depends on the livetable. There isn't really an alternative to launching a browser for testing our JS
components, since most if not all of them heavily rely on a DOM, so just a JS runtime will not be enough.
Absolutely true, but you need to lauch more than a browser for proper test, you had to test all of them. If I take the livetable, there is not much JS and the chance to break it by mistake is not so important, but on the other side, the risk to break it in one browser and not in another, is really bigger.
We could envisage a JS unit-testing system like this :
- Write tests in .js files, using JSUnit or any other unit testing JS framework (http://ejohn.org/blog/which-unit-testing-framework/) - Slurp the tests in a XAR using a maven plugin - Execute the tests inside XE, using Selenium
Unit testing would be nice, but functional test IMO will provide more. For functional test, you need to have more complete samples than just AllDocs. These samples could be nice demo of the capacities of XWiki, so it could be worth to write them. Also, extending current selenium test to other pages that use the livetable could be a simple way to start. Once again, I am sorry but I could not do that right now, but I would help as much as I can if you decide to go ahead. Denis
wdyt ?
Jerome.
I am not used to such automated testing, but I am not sure the investment is worse the improvement we could get from them.
On the other side, I use livetables JS heavily, so you could be assured that my fixes/improvements are either well tested or will be fixed ASAP since all changes I introduce is already in production. We also usually test them on all supported browsers, and at least on IE6/7/8, FF3 (Win/Mac), Safari4 (Mac) and Chrome (Mac) FYI, I found this one when we have introduced the usage of hashes to provide "Back to the list" links. I will soon commit an improvement supporting the page size in hash as well, so you can really get very precise "back to the list" return links.
Denis
Thanks
-Vincent
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
participants (3)
-
Denis Gervalle -
Jerome Velociter -
Sergiu Dumitriu