This is a page for listing tasks that are or appear to be difficult to accomplish in TestDrivenDevelopment.

* AutomatedInstallationTesting.  I'm considering embarking on an endeavor to produce a ShrinkWrapped Java application.  Since one of my biggest fears is smooth installation in a wide variety of environments, I want to work on that story early and do it TestFirst.  To do that, though, I believe I need to automate GUI interactions in a VirtualComputer.  So far, the only way I can see to do that is to buy a combination of software from IbmRational and VmWare totalling about $3,500.

----
The cost of your unit test fixtures aren't really a part of test driven development.

Whether you use TDD or not won't change how much it will cost you to have test environments ''(I didn't mean to imply that I thought it would)''. If you decide to do your installation testing after all the code is done, test environments will still cost the same. ''Or potentially cost even more since having test tools early on may help us to build a more testable installer, where as selecting the tools after the fact may require us to buy more tools or more expensive tools''

Anyway, if there's an equivalent to java.awt.Robot for Swing (or whatever Java gui toolkit your installer uses) then you only need a few spare PCs and a copy of the target OS on each PC.

----
That might be a starting point, but it would take some more thinking to get that to the point of a point-and-click test suite.  Somehow, before each test on each system, it must be set back to a known pre-installation state, including JRE version, etc.  What if I use the standard VmWare or VirtualPc (which can run a session without saving it), and have each session load a program on startup that sets up an IP link to the test harness already running...?

----
CategoryTestDrivenDevelopment