Jsp Refactoring Case Study
The Context
The role of programmer (in this context) consists of a number of duties:
- Writing JSPs and HTML
- Writing database insert scripts
- Writing XML or XSLT documents
- Writing Java code
We don't practice PairProgramming, and don't have many unit or acceptance tests.
The requirements consisted initially of a few screenshots from Visio showing an example of each page in the application. The application is a Web front end to a content management and distribution server.
This design did not include:
- the DataSource for dynamic data
- the ExpectedResult (i.e. next page) of clicking on a link
The defacto design pattern in use was StandaloneJsp.
The Ranting
I am, for the most part, expected to turn out code which plugs straight into the existing platform. Whether it's a JSP-based report, custom Java or JSP plugin, or even a number of interrelated components, the standard way of testing is to add it to the platform, turn it on, and see if it works. I might get to do this a few times on my local machine before it gets deployed to the test server, after which any problem becomes a bug report which goes straight to my mailbox if I'm lucky. If it's a bad bug someone will tell me verbally instead.
On Testing
In extremeprogramming@yahoogroups.com, "J. B. Rainsberger"
CarolineFoster wrote [in http://groups.yahoo.com/group/extremeprogramming/message/67515] - I have the same problem, but with my unit tests. I get six lines in, realise how much set-up there is and give up. [I'm working mainly with servlets and JSPs. I've tried Catcus, but I spend five minutes, realise how much setup there is and give up. Shame on me.]
AcceptanceTests are a different story, and are perfect for TestDrivenDevelopment. An example:
- Write (or preferably get a Web designer to write) a static version of the page.
- Write a Junit test to check the response and basic structure of the page.
- Write a test for a piece of dynamic content or expected UI action response.
- Add the dynamic data or action handler.
- Run the tests and repeat 3-5 until done.
Step 4 can (and should) lead to further refactorings, which can open up the possibility of having a reasonably defined "unit" which is capable of being tested independently. But if 5 passes then the pressure to move onto 3 (or maybe even straight to 4) for the next bit of functionality is very strong (at least in my world)...
In refactoring@yahoogroups.com, emily.bache@a... wrote [slightly edited]:
A couple of years ago I tried to refactor a large messy Java (partly J2EE) application, and it was a disaster. The code ended up so full of bugs it was unusable, after around 3 months of my time.
Reasons were:
- I wrote lots of unit tests, but they didn't cover the code base sufficiently to catch all the bugs I was introducing in my refactorings, let alone the bugs that were already there.
- I was inexperienced with unit testing and refactoring, not skillful enough to take on this size of a problem, and didn't realize it until too late.
- I didn't use an automated refactoring tool, and that might have prevented many refactoring mistakes.
- the code had a fair number of bugs in before I started.
- I had no acceptance (whole application) tests, manual or otherwise.
- I was not releasing partially refactored versions for manual testing by users - the horrible mess of bugs was only discovered at the end.
I am happy to say that I think I learnt from this experience. I am currently refactoring another application, and everything is working well. Some things I have done differently:
- starting with acceptance tests that test the whole application end-to-end.
- doing manual testing until I can get tests automated.
- releasing to end users often (at least once a month, usually every 2 weeks) - they find the bugs my tests miss, which so far hasn't been many.
- I am now more skillful with unit testing and refactoring after much practice over the past couple of years.
It helped that the codebase didn't have many bugs in to start with.