Exotic Database technology?
Most databases do something rather wonderful: they log stuff. Now, this doesn�t seem like a big deal until you consider the fact that the log consists of the commands used to define and modify the database. Further consider that the log can be played back to recreate the entire database and you�ve got something well beyond a big deal: it is pure genius. Little bits of genius like this exist throughout software. Often disguised as technology applicable to only a single problem, these bits wait patiently for someone to reevaluate them in a way that recognizes the greatness of the concepts behind them.
Let�s do some of that reevaluation now: What if an application worked just like a database? That is, everything the user did was logged and the log was defined such that playing it back caused the application to return to the same state it had reached during the initial user session? Such a capability could be used as a safety net for the user, providing a backup in case a document was lost or corrupted. It could be useful for tech support: with the log providing a detailed recounting of all users actions. It could be useful for training: where animated walk-throughs show the user how to do something. It could be useful in the development of the application itself: where each log functions as a test.
UI animation: The Player
We are particularly interested in this last variant: testing. Mindful of the many potential uses for this technology, we will code a simple, abstract infrastructure which could support any of them. Here is our first crack at it:
ControlSystem � heart of the Platform, routes Windows.Form events to handling objects.
Player � Runs a set of instructions, animating the UI.
StopWatch � adapter for System.Threading.Timer.
Instruction � Represents an individual action a user can take (MouseMove, LeftButttonDown, etc.).
We want the UI to look like a user is actually manipulating it: the cursor should move, buttons should go down and up, controls should change position during a drag. To create these effects, the Player must have access to all of the methods which drive the ControlSystem. The Player must also handle timing. Though we certainly want to run a set of instructions quickly when verifying multiple tests, we also want to run tests at normal speed to make sure they are executing correctly. StopWatch, which adapts a System.Threading.Timer, can give us control over this part of the solution. And finally Instruction, which emulates user actions, will give us the ability to manipulate parts of the UI programmatically. Let�s code a test and see how these might be defined:
ControlSystem.Player.Add(new MouseMoveInstruction(10, 10));
ControlSystem.Player.Add(new LeftMouseDownInstruction(10, 10));
ControlSystem.Player.Add(new MouseMoveInstruction(100, 100));
ControlSystem.Player.Add(new LeftMouseUpInstruction(100, 100));
By default the Player will execute each instruction every half second. We can change that by passing an additional argument (Speed) in the constructor. This code is valid and represents one kind of test. We can also get more �meta� if you like, passing the control to be dragged and the target DropSite in alternate constructors of these same instructions:
ControlSystem.Player.Add(new MouseMoveInstruction(dragSourceControl));
ControlSystem.Player.Add(new LeftMouseDownInstruction(dragSourceControl));
ControlSystem.Player.Add(new MouseMoveInstruction(dragTargetControl));
ControlSystem.Player.Add(new LeftMouseUpInstruction(dragTargetControl));
Assuming we have such capabilities, we could run the exact same tests introduced in the previous article via the Player. These tests will run more slowly, due to the delay, but they would also test the mouse handling system (the very same system which will process the mouse events of the Windows Form.) The net result is that these tests exercise more code, more realistically than direct calls on the classes themselves.
The development experience
After coding the initial implementation and watching the first test run, we noticed that it was difficult to determine when the test was complete. The cursor would sit over some control, leaving us to wonder: Is there one more instruction to go, or is this test done? To resolve this problem, we enhanced the Monitor to include an instruction log. An entry is added to the log each time an instruction starts and updated when the instruction completes. The new Monitor:
Using the Player
The drag cases from the previous article are coded as direct calls on infrastructure objects. For example:
protected override void Test()
{
ControlSystem.Mouse.Move(50, 50);
ControlSystem.Mouse.LeftButtonDown(50, 50);
ControlSystem.Mouse.Move(350, 350);
ControlSystem.Mouse.LeftButtonUp(350, 350);
}
These need to be changed to UI animation tests, by converting the code to this:
protected override void Test()
{
ControlSystem.Player.Add(new MouseMoveInstruction(50, 50));
ControlSystem.Player.Add(new LeftMouseDownInstruction(50, 50));
ControlSystem.Player.Add(new MouseMoveInstruction(350, 350));
ControlSystem.Player.Add(new LeftMouseUpInstruction(350, 350));
ControlSystem.Player.Play();
}
With the conversion complete, we run the tests and verify:
Once again we move forward under full green. We now have enough infrastructure in place to start coding controls - that will be the topic of the next article.
Thanks!
To all of you who are sticking with us in this article series, we say thank you! How are you holding up? We are at about 14,000 lines of source (both tests and code) at this point. The UI Platform proper sits at about 5,500 lines across 118 types). That�s a lot to keep up with; yes, we know. Obviously we can�t discuss every single line of code, but rest assured: all of the fundamental concepts have been covered. If it seems like the train is leaving the station without you, please feel free to provide feedback or send us an e-mail � we�d be glad to discuss anything that is on your mind.
Downloads
