I have been wrestling with is how to do XP on heavily GUI projects such as websites. There are two specific problems we have faced: 1) How to automate testing the GUI and the entire system through the GUI? 2) How to have unit tests for the GUI written before the GUI is written? For #1 we have some tools in house (eTest or eTester?) that record what a person does and then you can run the script that was generated as a regression/unit test. #2 has been more difficult. Since we use a script generation tool to create the tests a good part of the GUI must be in place for script to be worthwhile. How have other people been solving these problems? John
The only reason for time is so that everything doesn't happen all at once.
- Buckaroo Banzai
This is an area that I have been thinking a lot about. I am currently working with a client that does web frontends and we are wrestling with how to test end-to-end. The best I can do right now is to make two points. First, you want automated tests to make you life easier. If I can test from a proxy http server all the way through the back-end, that may be good enough. I would prefer to go all the way, but we shouldn't let the desire for a perfect solution prevent us from implementing a really good one. So, we have to balance the costs and benefits. Secondly, we need to concentrate on putting the things we need to test in locations where they can be tested. We have pretty good tools for testing Java code, so let's put as much of the stuff that can break as we can there. JSPs are more difficult to test so lets try to keep the breakable stuff out of there. And lets make the html as simple as possible so it can be handled with a minimum of worry. If we worry about the testing at the beginning we will find that it forces us to put things in the right place. chet
author of:<BR><A HREF="http://www.amazon.com/exec/obidos/ASIN/0201708426/electricporkchop" TARGET=_blank rel="nofollow">Extreme Programming Installed(The XP Series)</A>
I'm not sure that test first quite works for GUIs, certainly web interfaces. With a web GUI I like to fiddle around to get the right look and then snapshot the look along the lines of "tell me if this sucker changes". When you want to dig more specifically into fields then I find an adapter class that gives me a simple interface is easy to write and insulates me from specific changes. I can then write tests to that adapter and make changes to the look and feel without breaking them. For unit testing the key thing is to get as much complicated code out of UI specific things as you can. Not just is it easier to test, it's also a better design. Often making things easier to test leads to a better design.
author of:<br /><a href="http://www.amazon.com/exec/obidos/ASIN/0201485672/electricporkchop" target="_blank" rel="nofollow">Refactoring : Improving the Design of Existing Code</a><br /><a href="http://www.amazon.com/exec/obidos/ASIN/020165783X/electricporkchop" target="_blank" rel="nofollow">UML Distilled, Second Edition: A Brief Guide to the Standard Object Modeling Language</a><br /><a href="http://www.amazon.com/exec/obidos/ASIN/0201895420/electricporkchop" target="_blank" rel="nofollow">Analysis Patterns : Reusable Object Models</a><br /><a href="http://www.amazon.com/exec/obidos/ASIN/0201710919/electricporkchop" target="_blank" rel="nofollow">Planning Extreme Programming</a>
Joined: Apr 05, 2000
Joined: Dec 12, 2000
This is an unfortunately names topic since we seem to be concentrating on Web GUIs wheras I think most people are thinking Swing/AWT/Windows GUI at first sight. Nonetheless, I have been tasked with providing a project framework to allow collaborative work between server-side Java developers and web content creators and graphics artists. Like everyone here has learned, this is tough. And, like everyone, we have created a process that works for us. First and foremost, we have automated as much of the building and deploying of the application as possible. Our testers work with an internal version of the site that is recreated twice a day. The build and site deployment is capable of being performed on a user's workstation or in a server farm with a couple of command-line arguments. As for the web content, we spent a lot of our design time creating a system with which content can develop with little or no knowledge of the back end. Using standardized XML responses or JSP taglibs, the content writers create and prototype without ever really caring what the developers are doing. They simply put code or placemarkers where results should be returned. Getting dynamic information is no different than writing image tags. This has worked very well for us so far. Now, if we could only incorporate XP into the developer side of things, I'd be very happy. I think we can since: we're under 15 people, are pretty much paired off already, have little in the way of process other than coding standards and configuration management standards. Jesse
Joined: Apr 05, 2000
Hmm... You're right. The topic may be a little misleading but I didn't think to write XP and Web GUI Projects at the time. Your comment sparked my (somewhat) fond memories of working on a Swing-based GUI. All I had to do there was write some JUnits! Oh, well... John
Joined: Dec 11, 2000
Originally posted by John Wetherbie: Martin - When you discuss adapter classes I am assuming that you are talking about GUIs that are implemented in Java (in some form). I don't see much of this at all. We pretty much use HTML with a few JSPs for our interfaces.
You can actually still do an adapter for testing here. The adapter would take the HTML page and pull information out of it. That way you can usethe adapter in assertEquals("drunk", currentStatus()). Saves you encoding the code to dig into the HTML text in your test class. But most of the time a straight compare of the whole HTML does the trick and is much simpler (and you know how much we like simplicity). I gather this is how httpUnit works (although I haven't played much with it.
[This message has been edited by martin fowler (edited December 13, 2000).]