Home > Archive > Extreme Programming > September 2005 > Testing UI application - Any good approach
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Testing UI application - Any good approach
|
|
| robben 2005-08-19, 4:15 pm |
| Hi All,
I have been using cppunit for some time to write unit testing test
cases for business logic.
I have a requirement to test the UI of the application and found/heard
that using CPP Unit is not a good Idea.
I was suggested to use some recording tool like RationalRobot to record
the UI and check with the recorded UI when ever there is a change in
the codes, but found that it is not suitable for me as my application
uses too many test simulators and to synchronize all of them is
difficult.
I would like to know the approaches you use in your company to test the
UI.
Thank you.
| |
| robben 2005-08-19, 4:15 pm |
| SORRY MY MISTAKE FOR POSTING TWO SIMILAR ITEMS, PLEASE IGNORE THE FIRST
ONE.
robben wrote:
> I would like to know the approaches you use in your company to test the
> UI.
> Thank you.
| |
|
| robben wrote:
> I have been using cppunit for some time to write unit testing test
> cases for business logic.
Is this test-first or test-last? Are you implementing code as you go, or
testing someone else's implementation.
> I have a requirement to test the UI of the application and found/heard
> that using CPP Unit is not a good Idea.
Why not?
> I was suggested to use some recording tool like RationalRobot to record
> the UI and check with the recorded UI when ever there is a change in
> the codes, but found that it is not suitable for me as my application
> uses too many test simulators and to synchronize all of them is
> difficult.
If you have a business GUI, then everything in your GUI has an in-memory
representation. For example, if your production code calls SetWindowText (or
a derivative) to push text into an edit field, then your test code can call
the matching GetWindowText to pull the text out and check it.
This principle is called "Just Another Library". Create a window, mess with
its controls, and destroy the window, all without invoking your message
loop.
http://www.c2.com/cgi/wiki?TestFirs...facesPrinciples
--
Phlip
[url]http://www.greencheese.org/Z Land[/url] <-- NOT a blog!!!
| |
| Johnny Lee 2005-08-26, 7:56 am |
|
robben wrote:
> Hi All,
>
> I have been using cppunit for some time to write unit testing test
> cases for business logic.
> I have a requirement to test the UI of the application and found/heard
> that using CPP Unit is not a good Idea.
> I was suggested to use some recording tool like RationalRobot to record
> the UI and check with the recorded UI when ever there is a change in
> the codes, but found that it is not suitable for me as my application
> uses too many test simulators and to synchronize all of them is
> difficult.
>
> I would like to know the approaches you use in your company to test the
> UI.
>
> Thank you.
Maybe you can record the data before it sent to the output buffer.
For example, you can write the data to a file, and diff the two file
when you make changes to your code.
| |
| Guillermo Schwarz 2005-08-28, 6:56 pm |
| robben wrote:
> Hi All,
>
> I have been using cppunit for some time to write unit testing test
> cases for business logic.
> I have a requirement to test the UI of the application and found/heard
> that using CPP Unit is not a good Idea.
> I was suggested to use some recording tool like RationalRobot to record
> the UI and check with the recorded UI when ever there is a change in
> the codes, but found that it is not suitable for me as my application
> uses too many test simulators and to synchronize all of them is
> difficult.
>
> I would like to know the approaches you use in your company to test the
> UI.
For testing the whole UI you need testers running on Staging machines,
making sure that all business use cases handle correctly all corner
cases. XP suggests that you should automate all tests. I like their
explanation, you can do the extra effort, but someone must make sure the
whole system is usable. Usability tests are by definition manual. Issues
found in Staging should be entered into IssueZilla or something
simmilar. XP proponents suggest that you use unit tests to keep track of
the issues. That's a nice idea, I've used it and it really works. The
only problem I have with it is that you need something like Scrum to
convince management that you know what you are doing.
For testing each UI component you can write automated tests or a visual
component that test another visual component. Both approaches are time
consuming but they are worth the extra effort when integration time
comes. Also it is a lot more valuable to automate those tests, since no
one can test again if your star button still works.
Cheers,
Guillermo.
>
> Thank you.
>
| |
| robben 2005-08-28, 9:56 pm |
| Thanks to Guillermo, Johnny, Philip for giving me new pointers to the
problem, atleast I can now explore on the solutions provided by you, to
check if they solve my problem.
| |
| Chris Hanson 2005-09-03, 3:56 am |
| On 2005-08-18 18:12:46 -0700, "robben" <devendermarri@hotmail.com> said:
> I have been using cppunit for some time to write unit testing test
> cases for business logic.
That's always a good thing to hear!
> I have a requirement to test the UI of the application and found/heard
> that using CPP Unit is not a good Idea.
You can actually go rather far just using a normal unit testing
framework like CppUnit when testing your user interface. Phlip has one
good approach that he suggests, and has written a book about.
I have another approach I call Trust, But Verify. I wrote about it on my blog:
<http://www.livejournal.com/users/chanson/118380.html>
Obviously on my blog I'm talking about using it with the Cocoa
framework and the Objective-C language on Mac OS X. But that's not the
only place it applies, so here's a more general summary of the
technique: If you're using an existing object-oriented framework to
build your application, you can generally trust that the framework will
work as long as your application is connected to it properly.
So to test your interface layout, you should just be able to load your
interface from the resource files it's defined in and check that the
controls are placed and configured like they should be. You shouldn't
need to show anything on the screen, interact with your application, or
even interact with your framework's event queue to do this.
To test your interface "behavior," you should just be able to load your
interface from the resource files it's defined in and check that the
connections between your interface and your application code are set up
properly. E.g. that your controls are set to generate the right event
codes, or invoke the right action methods, or that the right delegates
are set, or whatever. Again, you shouldn't need to show anything on
the screen, interact with your application, or even interact with your
framework's event queue to do this.
All of the above you can do with a standard unit testing framework like
CppUnit, you don't need capture and playback tools for it. Your
behavior tests can also be more flexible in the face of layout changes,
while you can actually do Test-Driven Development to handle both
behavior and layout changes (which is nearly impossible with most
capture and playback tools).
> I would like to know the approaches you use in your company to test the
> UI.
Just in case it's not clear, everything I say is just my personal
opinion and recommendation. I can't speak for my employer.
-- Chris
|
|
|
|
|