On Fri, May 21, 2010 at 14:05, Vincent Massol <[email protected]> wrote:
> > On May 21, 2010, at 1:29 PM, Denis Gervalle wrote: > > > On Fri, May 21, 2010 at 12:05, Vincent Massol <[email protected]> > wrote: > > > >> > >> On May 21, 2010, at 12:04 PM, Vincent Massol wrote: > >> > >>> Hi Denis, > >>> > >>> On May 21, 2010, at 11:34 AM, Denis Gervalle 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. 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. > >> > > > > 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 ;) > > 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. > I know that, but there is a large difference between testing a working AllDocs document, and testing all functionalities of the livetable. It would require writing some intelligent sample, using all kind of filter, column type and so on... > > 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 > > > 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. > I completely agree with you, and I am not only _using_ XWiki, but also improving it as much as can. When I say "usage" here, I am just saying that I do not just develop improvement, but I do use it on production platform, which ensure I will have a lot of chance to receive any negative feedback on my side before XWiki release is done. This also means that I am really confident on the changes I am introducing. Since I am doing so since 0.9, I imagine that I do so on the long term ! What has changes since I am commiter is that I am now able to share what I have already done, and also extend or think about what I need for my customer from a more generic PoV and therefore improve the product on a larger scale. I d'love to see XWiki more good and stable, and especially more spread. > 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. > I also agree, and you (with others, and myself, I hope) do a great job for improving the quality and architecture of the project. And we also agree that the UI has not been taken enough attention. What I try to say is that it is urgent to first improve it to increase our "market share" in the short terms, since we are not alone on this market, and we need to impose us, not only to technicians but also to end users. Having feature like "forgot password" broken, having a blog application that is not fully working (yes, this is my feeling), having complex rights management, still having complexity and issues in languages management, and a WYSIWYG editor that does not allow simple left/center/right alignement, etc... currently impact my ability to convince our customers to adopt XWiki. And you know how it is, if I cannot pay myself, I will have to work on something else, something I really want to avoid, since I really like working for XWiki. 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. > Well, there also I agree with you. But, I would still prefer someone to commit a fix without test, then leaving the issue open. The current thread is about a fix on an issue that is there since the new hash functionality has been introduced in the livetable. If there were a test for that functionality, I would have update it. But there is even no test for anything in livetable currently. The improvement I have added recently to livetable has also suffer of the same situation. But, choosing between not having them at all, or having them without test, but being careful on it, I have choose the second option, and I have proposed them to votes ! That was the time to disagree on functionality if you really think missing test is worse a -1. 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. > I would be pleased to do so as soon I have time for that. I even agree that I am a good candidate to do so. But I am currenlty working on improving the Blog Application, since it is currently almost useless for us and I suppose others, since my improvement are absolutely generic, and aims to allow more autonomous blogs. I expect to also share these improvements. Once again, you will say, hey Denis, the testing of the application is poor, you should improve it... but you should have request them from the first writer ! If I were rewritting the whole application from scratch, I will understand that missing test is blocking, but I do not agree, when I make small improvements only. So I am again sorry not being able to reach your expectation right now, but I really feel the needs to fix what will helps me increase sales, and I do it while taking care of keeping good quality and making improvement generic enough to be redistributed. Once I get to the point that what exists is working properly enough and have a good usability allowing the sales to market the product properly, I will be more than happy to increase the amount of automated testing. In the meantime, I commit to maintain existing tests, and improve them when it is trivial to do so. I hope you better understand my opinion here. This is not laziness but more a matter of priority. 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). > This is probably where I do not fully agree with you. The automated quality control of the UI side is not the _next_ step for me, this is a _future_ step, but I feel we have more immediate steps to stabilize features or have them improved to the current level of the competition. We are not Google, we do not have their work force and this is why I sometime feel that you exceed on quality control, while at the same time there is really and sometime well know place that need immediate and quick improvement, event dirty fix, just to make the product usable. And do not change anything, you should continue to insist on QC, but I think you should also be more pragmatic at time. 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. > As we all do, and I am also curious to know what others have to say on our discussion. > > >>>> 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 > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
