'''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" wrote [''slightly rephrased'']: I have trouble writing AcceptanceTest''''''s, rather than UnitTest''''''s. 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.] AcceptanceTest''''''s 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