Recording (And Playback) Of User Actions In Java?

mnalsky asks: "I need an automated system for Java applications testing. I'd like the system to be able to record user session of Swing application and dump it to a file. Then one can play back this file and the application will repeat all of the steps. I've searched through the Web for it and have found nothing. Sun had its tool JavaStar, but in November, 1999 they stopped developing it. Now it's not possible to download JavaStar from their Web site, and I can't find it anywhere else on the Web. Are there any other tools like this? Is JavaStar available somewhere that I might have missed?"

Comments

java.awt.Component.dispatchEvent

[_xeno_]

How about this: override dispatchEvent in the base UI, so that it records the events that have taken place here. Save the event to a file using the serialize methods. Make the logging part optional, probably based on the existance of an java.io.ObjectStream. Then call super.dispatchEvent() to do things normally.

When you want to play back the user's actions, disable logging, and then call dispatchEvent() with each of the deserialized events. That should give you a play-by-play exact copy of everything the user did (including moving the mouse...)

This won't work if you have multiple windows unless you're creative... so be creative with it.

Standard disclaimer that this doesn't represent professional advice and I've never tried it, but it might work...

(Also, an AC mentioned java.awt.RobotThis class is used to generate native system input events for the purposes of test automation, self-running demos, and other applications where control of the mouse and keyboard is needed. The primary purpose of Robot is to facilitate automated testing of Java platform implementations.)

Re:Pretty simply theoretically, but probably a pai

[martyb]

I HIGHLY recommend checking out the FAQ for the usenet group: comp.software.testing . It can be found at: http://www.faqs.org/faqs/soft war e-eng/testing-faq/ or at: http://www.cigital.com/c.s.t.faq.html

There's MUCH MORE to automated testing that just recording and playing back keyboard/mouse input.

Here are some of the issues that need to be dealt with:

1. Timing. (It's hard to click a button, if it ain't there, yet.) Different versions of the Application Under Test (AUT) may run at different speeds (better/worse performance) on the same system, or you may try to run the same automated test on different (faster/slower) platforms. In either case, there's a need to wait until *something* has happened, and only then feed in the next input.
2. Location. Minor modifications of the AUT may cause fields and buttons to be relocated. Hard-coded locations in your test scripts are a PAIN to maintain!
3. Verification. How do you know if it did what you wanted it to?
   • Screen capture? Again, minor screen layout changes force major maintenance headaches.
   • Date/Time and other varying output. If your Application puts up a date or time on the window, you're gonna need a way to mask that out between prior and current runs so it doesn't give you a false negative.
4. Error Handling. The whole idea is to deal with an application that might not run the same every time. That means needed to determine all possible outcomes, and to be able to deal with them, too. (It's all too easy to get into deadlocks where the application is expecting input, and the test program is waiting for some other screen to display before it sends any keystrokes to it.)

I could go on and on, but this hopefully gives a hint to the complexity and difficulty in automated testing. (And, yes, I've stumbled upon ALL of these myself at one time or another.)