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.
http://www.testearly.com/resources/selenium-ant/full-
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.
Well.
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?
/Janne
