Jsp Refactoring Case Study

The Context

The role of programmer (in this context) consists of a number of duties:

1. Writing JSPs and HTML
2. Writing database insert scripts
3. Writing XML or XSLT documents
4. 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" <jbrains@r...> wrote [slightly rephrased]: I have trouble writing AcceptanceTests, rather than UnitTests. Every time I try to write an acceptance test, I get six lines in, realize how much set-up there is and give up. The test is simply too big. I wonder whether an emphasis on unit tests makes it too difficult to write good acceptance tests.

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:

1. Write (or preferably get a Web designer to write) a static version of the page.
2. Write a Junit test to check the response and basic structure of the page.
3. Write a test for a piece of dynamic content or expected UI action response.
4. Add the dynamic data or action handler.
5. 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.

---

CategoryCaseStudy, CategoryRefactoring