aspose file tools*
The moose likes Agile and Other Processes and the fly likes XP and GUI projects Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of JavaScript Promises Essentials this week in the JavaScript forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "XP and GUI projects" Watch "XP and GUI projects" New topic
Author

XP and GUI projects

John Wetherbie
Rancher

Joined: Apr 05, 2000
Posts: 1449
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
chet hendrickson
Greenhorn

Joined: Dec 12, 2000
Posts: 10
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>
martin fowler
Author
Ranch Hand

Joined: Dec 11, 2000
Posts: 53
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>
John Wetherbie
Rancher

Joined: Apr 05, 2000
Posts: 1449
Martin & Chet,
Thanks for the info.
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.
We definitely do our best to separate presentation for most types of logic (routing, business, etc.) but we do have javascript, in appropriate places, to validate inputs. We could put a servlet or something behind the HTML to do the checking but I really hate to propogate bad data that can be caught on the client side.
So that's why we worry about unit tests and functional tests that hit the GUI.
John
chet hendrickson
Greenhorn

Joined: Dec 12, 2000
Posts: 10
John,
Just as a footnote, there are a couple of javascript unit testing tools available at www.xprogramming.com.
chet
Jesse Tilly
Ranch Hand

Joined: Jun 25, 2000
Posts: 37
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
John Wetherbie
Rancher

Joined: Apr 05, 2000
Posts: 1449
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
martin fowler
Author
Ranch Hand

Joined: Dec 11, 2000
Posts: 53
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.


We definitely do our best to separate presentation for most types of logic (routing, business, etc.) but we do have javascript, in appropriate places, to validate inputs. We could put a servlet or something behind the HTML to do the checking but I really hate to propogate bad data that can be caught on the client side.

Yeah, JavaScript is a pain. I haven't played with the JavaScript tools that Chet mentions - but my habit is to put as little logic in JavaScript as possible - that way there's less to break. I would do as much checking on the server side as possible - it's easier to change, easier to test, easier to satisfy OnceAndOnlyOnce. Only use javascript if you absolutely must not have the round trip before validation.
Martin

[This message has been edited by martin fowler (edited December 13, 2000).]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: XP and GUI projects