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?"

Take a look at XD/Replay

[Anonymous Coward]

XD/Repl ay can record and play back user actions in java applications. Xd/Replay may or may solve mnalsky's problem; I'd need more details to say for sure. [ed.ac.uk]

Look at Mercury Interactive's products

[svetz]

NOTE: I'm writing this on a computer owned by Mercury Interactive.

Mercury (http://www.merc-int.com) has two products that may help you - WinRunner and XRunner. They are commercial only, and I don't know of free demos available. You get a powerful C-like scripting language and a complete IDE for recording, debugging and replaying the scripts. If I say more, I'll be accused of advertising :-)

The more advanced, Windows only, product is WinRunner. It also supports native Windows apps, Deliphi, ActiveX, and probaly other stuff I haven't heard about. Last time I saw it, XRunner was a tiny bit behind on the user-friendly side. It's basically Unix version of WinRunner, (only Solaris, HPUX and AIX - no Linux, but if you show interest, they just might go ahea and do it). Supports Java, Motif and Ilog.

I don't know about pricing of these products, so I can't help you decide if it's on you're budget. You'll have to contact Mercury to see about that.

Re:java.awt.Component.dispatchEvent

[_xeno_]

You see, it takes Slash to take something that was written correctly and change </a> into </a&g t;, and then decide that the remaining bits (which were a tag) should be ignored. That should have read: java.awt.Robot [sun.com]

This 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.

In the 1.3 API

[stubob]

With the java 1.3 release, Sun added this functionality with the java.awt.Robot class. From the API:

This 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.

Using the class to generate input events differs from posting events to the AWT event queue or AWT components in that the events are generated in the platform's native input queue. For example, Robot.mouseMove will actually move the mouse cursor instead of just generating mouse move events.

Note that some platforms require special privileges or extensions to access low-level input control. If the current platform configuration does not allow input control, an AWTException will be thrown when trying to construct Robot objects. For example, X-Window systems will throw the exception if the XTEST 2.2 standard extension is not supported (or not enabled) by the X server.

So basically you can create a test class with an instance of Robot and give it all the commands you need to do. It will mimic keyboard and mouse input, and will also perform screen captures if you want. I wish they had this for my last project using 1.2. It would have made life a lot easier.

My take on this:

[AFCArchvile]

Java macros: GOOD! Think of what we could do with this.

Java user tracking: BAD! Your actions are already bogged down by that damned JavaScript; now it's tracking your every nuance and move? UGHHHH!!!!

Pretty simply theoretically, but probably a pain..

[Slynkie'sEvilTwin]

The way I see it, there are only so many ways a user can give input to a java program (most java programs, at least)...

1. keyboard presses
2. mouse moving
3. mouse clicking

all of which are handled by actionListeners (forgive me if my terminology is off, i haven't coded java in a year or so)...so, you keep some sort of vector type thing that holds a list of actions the user has performed. whenever one of the above events occurs, all you need to do is create an entry with the coordinates/key/whatever, and you have your record.

the only thing you might wanna do is rather than recording a button press as simply "MOUSE_RIGHT_DOWN at 230,230", actually indicating a button directly would speed it up a bit...although it'd make for slightly harder parsing in playback.

dunno, doesn't seem like too huge a thing to me, although i can't say much for how efficient it'd be...

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.) [sun.com]

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/ [faqs.org] or at: http://www.cigital.com/c.s.t.faq.html [cigital.com]

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.)