21 May
2010
21 May
'10
2:05 p.m.
On May 21, 2010, at 1:29 PM, Denis Gervalle wrote:
On Fri, May 21, 2010 at 12:05, Vincent Massol
<vincent(a)massol.net> wrote:
This is already done Denis, you can check it out in selenium-tests. There's no test
specific for the livetable but there are tests for AllDocs (for example) which test some
basic features of the livetable.
So what is needed:
1) extract the livetable test part to ui-tests since that's the new architecture for
new tests
2) add new livetable tests
On May 21, 2010, at 12:04 PM, Vincent Massol wrote:
Fine, so I let you write all the tests for the initial and basic live table
functionalities, and once these are available, I will complete them to test
the new features I have recently added ;) Hi Denis,
On May 21, 2010, at 11:34 AM, Denis Gervalle wrote:
> On Thu, May 20, 2010 at 19:23, Vincent Massol <vincent(a)massol.net>
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. I am not used to
such automated testing, but
I
> am not sure the investment is worse the
improvement we could get from
them.
It's always worth it.
Note that the hard part is getting started with it. Once you have your
first test, it's usually very easy to add a second test afterwards and it
doesn't take long.
So, just to be serious, I completely agree with you
regarding the advantage
of automated tests. But my current feeling about XWiki and its current UI is
that we are not moving fast enough compare to the competition. As well as
there is great components (ie new rendering), there are on the other side a
really bad/complex/tricky/not working UIs compare to similar products. If I
want to be able to continue my contribution on the project (and I d'like
to), I have to concentrate on improving the end user experience first, and
gets new clients paying for my work.
So I am sorry if I cannot currently meet your quality expectations, I just
hope that my intensive usage and testing already helps improving the product
quality, since this is the best I can do right now.
IMO people should not be a committer because they're using XWiki for their projects.
They could just be a contributor for that. A committer goes beyond this. You become a
committer when you're interested in the product on the long term and to make it good
and stable.
We've been trying to improve the quality of our software and I've noticed a trend
lately that goes in the other direction, especially for UI-related things. This has
resulted in several UI things broken in recent releases that we discovered too late. Note
that Marius is doing a great job in writing automated tests whenever he makes changes to
the WYSIWYG editor and that's great.
Note that this is not directed just at you but at all of us (me included). I'd like
that when someone commits something without a test that could be written relatively easily
then other committers should ask that person to add tests, in an effort to improve our
global quality.
I understand you're busy but since you've been doing several modifications to the
livetable already and are planning to continue making improvements to it, it would be
great if you could manage your time to find some time to start a test suite for the
livetable at some point (when you find some free time). At the same time that'll allow
you to discover how we write functional tests, which is a must know for all XWiki
committers IMO.
Thanks
-Vincent
PS: Just so my message is not understood wrongly: I really love the work you've been
doing so far since you joined XWiki as a committer. It's great and it's helping
the project a lot and I thank you for this. I'm just trying to get us all to the next
step which is to control our quality on the UI side (on the java side, it's almost a
practice that is always followed).
PPS: I'm talking for myself here and not representing the dev community. I'm
curious to see if other devs agree with what I've said or not.
>>> 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.
>>
>> While this is good enough for you as an individual we cannot rely on this
> at the project level. We do need absolutely automated tests written for
> everything that gets committed to ensure the quality of XWiki releases.
>>
>>> 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
>>
>> So you could either write a functional tests using ui-tests or define a
> new strategy for testing "XWiki UI Components".
>>
>> IMO you should start with livetable tests in ui-tests.
>>
>> Thanks
>> -Vincent