One of the great practices of agile programming is the use of unit tests, especially as a scaffold upon which solid code can be written. Laurent Bossavit has written about how life was before: we used to spend much more time in the debugger.
On my latest project, I've been working on a web site written in ColdFusion. First, let me mention the advantages of ColdFusion over something like J2EE.
- It is easy to learn, even for people with minimal programming experience. (The HTML-like syntax seems designed to appeal to people who are more comfortable with tags than with traditional code.
- It takes takes fewer hours, billable or otherwise, to produce a working web site
ColdFusion is very page centric. Typically, you'll find a mixture of code, HTML and SQL all in one place, on every page. There is no separation of view, model and controller. There are no units that can meaningfully be tested on their own.
More recent versions of ColdFusion do have support for a more object-oriented approach. Macromedia touts CFCs. There is at least one reasonably sophisticated framework based on CFCs. However, that's not the way most existing ColdFusion code is written.
Does it make sense to try to use automated testing at all? Rod Johnson's
J2EE
Design and Development (an book I've mentioned
before and don't mind recommending again) has some relevant
thoughts. He recommends the
HttpUnit class library
as an excellent, intuitive way of implementing web-tier acceptance
tests using JUnit.
The HttpUnit approach is essentially white-box acceptance testing. It has the advantage that we test our application exactly as it will be deployed in production, running on the production server. It's also easy and intuitive to write test cases. The drawback is that screen scraping can be vulnerable to changes in an application's look and feel that don't reflect changes in functionality (a frequent occurence).
HttpUnit does do a lot of the donkey work. It a imitates a web browser
fairly well: it supports cookies, frames and even (to a limited extent)
JavaScript. Another project,
jWebUnit, builds on top
of HttpUnit. To quote from the site, The simple
navigation methods and ready-to-use assertions allow for more
rapid test creation than using only JUnit and HttpUnit.
In other words, jWebUnit lets you write the same tests using fewer lines
of code.
I can use jWebUnit to write tests for the site. I can run the tests in an automated fashion. I can even write a launch-and-forget ant script. Now I need to see how effective a practice this is and what I learn as a result.
if you need to you can also do screen scaping with coldfusion just like httpunit, and you can do testing, I put all my test as cutomtags and call it from 1 cfm and see the test results as web pages. CF can do anything JSP can do with 1 /tenth the code, If you like typing Choose JAVA/JSP if you just want to get the job done CF is your choice
I agree, ColdFusion is better than JSP at what it does. JSP shares with CF the problem of how to do unit tests. Web pages just don't lend themselves to that kind of testing.
Hence my dilemma: I want to test and I want to test early, at a low level, but how?
I found a way to do automated testing, as did you. Today, a few months and one site redesign later, none of my tests work any more. It was an interesting exercise, but I have my doubts about whether it was worth it.
Having said that, I'd be interested in seeing more information, for example, what screenscraping and unit testing look like when done properly in CF.
ColdFusion is a great time saver when it comes to developing web sites. In the one case I know of first-hand, the CF site is much better in many ways than the Java/JSP site it replaced. I also have to say that it's relatively easy to write poor, unmaintainable code in CF and a lot of people do it. The same is true of Java but that's where practices like unit testing come in. In other words, there's more to it than just churning out code as fast as possible.
I use jWebUnit on a current project and yes, it is tricky to test the website correctly.
I focus my tests on the content (it is a data-entry application), and use it as an integration test: entry of a new policy, try to create another policy with the same number (which should fail), retrieve the new policy and check whether the data is the same as it was entered.
The biggest problem I face is the changing of ID's (for example the title of the page) and navigation.