incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Janne Jalkanen <>
Subject Re: JSPWiki 2.6.0 release
Date Tue, 27 Nov 2007 19:13:48 GMT
> On the positive side, if we were able to figure out a way to make  
> Selenium and Moo work together, it would be a GREAT way to do web  
> unit tests. It is **really** slick. Here's a demo MOV that shows  
> how to "record" unit tests. And although the movie doesn't show it,  
> you can export these as JUnit tests.
> functional_viewlet_swf.html

Yes, it looks very nice.  That would make it pretty easy to develop  
web tests, and we might get a lot of them.

> For example, if you turn off JavaScript and navigate to the  
> Login.jsp page, if you click on the "Register New User" tab, you'll  
> find that it doesn't do anything. This is exactly what happense  
> with JWebunit now, because we don't package Rhino with the web  
> testing tools (yet). It can't follow the JS link that activates the  
> registration tab.

We do ship with Rhino, but it's not used in the webtests suite.

> Even worse, if I try to access /templates/default/ProfileTab  
> directly, I get the dreaded NPE.

One of the reasons why the templates should be in WEB-INF...

> 1. How did we get to a point where the web tier became totally  
> untestable?

Nobody could run the web tests - I couldn't run them even for 2.4.   
So nobody ran them.  So nobody cared.  So they were broken.

> 2. Did we ever make a decision to require JavaScript to do even  
> minimal things like registering users?

No.  Then again, we never decided NOT to require it either.  In fact,  
we never discussed accessibility requirements for JSPWiki.

As much with open source, things just... happen.

> 3. How should we fix web tier testing? In the short term, we can't  
> even "cheat" and access the registration page directly.

Depends.  The simple short term solution is that we could drop in the  
old default template (as "olddefault"), and use that.  It should  
really work with minimal modifications (the editors would need to be  
fixed to conform to the new SpamFilter policies).

> 4. Do we care enough to delay 1.6.0? I do, but perhaps I am the  
> only one.


The reason I would like to release 2.6 asap is that it would allow us  
to move our development into Apache and start working on ripping out  
LGPL dependencies, and really work towards the 2.8 release, or the  
"Apachified 2.6".  So at best, 2.6 will be a "stopgap" release.

What extra confidence do we gain by getting the unit tests running  
which we cannot achieve by running a manual test cycle on our current  
UI? The point of automated testing is to make sure that the developer  
does not accidentally break functionality while refactoring/adding  
new features.  If we've stopped refactoring, we should be able to run  
the tests manually, and gain confidence in the system working enough  
for a release.  After that, when new work starts, we would gain a lot  
by having a FuTe suite, obviously.

A concrete proposal would be that instead of trying to fix something  
that we're planning to ditch anyway, we could split the existing unit  
tests among the developers on this list (should amount to a few per  
person, tops), and have everyone examine the code and run them  
manually.  Then collect the results on a single wikipage.

Then fix any excess bugs, release 2.6, move code to Apache, and write  
a big, bold issue report "Web tests need a-fixin'" and make it block  
2.8.  And hope someone takes it to heart to start working on it...

How does that sound?


View raw message