Re: [xwiki-devs] [xwiki-notifications] r28950 - platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table
21 May
2010
21 May
'10
12:32 p.m.
----- "Denis Gervalle" <dgl(a)softec.lu> wrote:
On Thu, May 20, 2010 at 19:23, Vincent Massol
<vincent(a)massol.net>
wrote:
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.
On May 20, 2010, at 7:15 PM, dgervalle (SVN) wrote:
platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table/livetable.js
Author: dgervalle
Date: 2010-05-20 19:15:53 +0200 (Thu, 20 May 2010)
New Revision: 28950
Modified:
> Log:
> XWIKI-5212 - Livetable filter serialization does not properly
support
multi-valued form elements
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. Merge from trunk r28947
Do we have a test for this? How do we unit-test UI components?
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 
21 May
21 May
1:15 p.m.
New subject: [xwiki-devs] [xwiki-notifications] r28950 - platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table
On 05/21/2010 12:32 PM, Jerome Velociter wrote:
----- "Denis Gervalle"<dgl(a)softec.lu> wrote:
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.
On Thu, May 20, 2010 at 19:23, Vincent
Massol<vincent(a)massol.net>
wrote:
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 ?
On May 20, 2010, at 7:15 PM, dgervalle (SVN) wrote:
platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table/livetable.js
Author: dgervalle
Date: 2010-05-20 19:15:53 +0200 (Thu, 20 May 2010)
New Revision: 28950
Modified:
> Log:
> XWIKI-5212 - Livetable filter serialization does not properly
support
multi-valued form elements
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. Merge from trunk r28947
Do we have a test for this? How do we unit-test UI components?
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/
1:39 p.m.
New subject: [xwiki-devs] [xwiki-notifications] r28950 - platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table
On Fri, May 21, 2010 at 12:32, Jerome Velociter <jerome(a)xwiki.com> wrote:
----- "Denis Gervalle" <dgl(a)softec.lu> wrote:
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
On Thu, May 20, 2010 at 19:23, Vincent Massol
<vincent(a)massol.net>
wrote:
platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table/livetable.js
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:
>
Log:
> XWIKI-5212 - Livetable filter serialization does not properly
support
multi-valued form elements
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. Merge from trunk r28947
Do we have a test for this? How do we unit-test UI components?
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.
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
-Vincent
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5232
days inactive
5232
days old
2 comments
3 participants
participants (3)
-
Denis Gervalle -
Jerome Velociter -
Sergiu Dumitriu