Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

XP and GUI projects

 
John Wetherbie
Rancher
Posts: 1449
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
chet hendrickson
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
martin fowler
Author
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
John Wetherbie
Rancher
Posts: 1449
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
John,
Just as a footnote, there are a couple of javascript unit testing tools available at www.xprogramming.com.
chet
 
Jesse Tilly
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1449
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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).]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic