Andrew Stopford's Weblog

I'd like to the ability to 'record' a set of interactions with my application.  These would then be played back as a part of a test.  I should be able to easily parameterise the input that is typed during the recording.  So the scenario is:

1) start my app in record mode.

2) navigate through menus/screens to a particular place.

3) type some input, select some items from a list.

4) produce some output from the app.

5) close app and stop recording.

6) go to the recorded script and replace my typed input with %1, replace list.selectedindex = 13 with list.selectedindex = %2 and save.filename = %3

7) construct a test database that has various values for %1, %2 and %3 as well as expected outputs

8) write a routine to compare outputs and call this at the end of the script

9) run the test script using the database to change the input.  The outputs would be saved to a folder and the function would return pass/fail.

Basically I don't want to spend days writing GUI test code (using White) like this:

app = Core.Application.Launch(strAppLocation)

winMain = app.GetWindow(Core.UIItems.Finders.SearchCriteria.ByAutomationId("frmMDI"), Core.Factory.InitializeOption.NoCache)

mdicld = winMain.MdiChild(Core.UIItems.Finders.SearchCriteria.ByControlType(System.Windows.Automation.ControlType.Pane))

but = mdicld.Get(Of Core.UIItems.Button)("Button_Next")

etc

Thanks

mattpil29 @ google mail . c o m

I would like to see it super fast and error free.

Pingback from  Dew Drop – March 24, 2010 | Alvin Ashcraft's Morning Dew

I would like it to be easier to code based on action rather than having to tell the applcation how a task should be done. In VS2010 as well as in previous version, you did the standard OOP coding where you have to tell the code to declare a variable, when to use it and so on. I would like to just pull a diagram onto the screen and it has auto-generated code that has my intent- like create a form whereby users can input standard form-information like name, address etc. Now, all I go to do is tweak it a little to suit my business needs if need be the case.  Standard OOP coding is getting stale and we need to look at new areas if we want to create better applications.

Listed in the order of importance to me.

1. Better extensibility. 2010 has made improvements, but it's still overly complicated extending the test framework.

 1a. First of all, registering DLLs is a non-starter. If a test project has referenced the DLL, the testing framework should be able to consider it an extension and go with it. End of story.

 1b. We shouldn't be locked into the current attributed class/method structure. Just give me an interface to define that returns a collection of tests to run, and let me go.

2. A new test runner. The current runner's use of a table for display is barely usable for the vanila style tests. As tests become more complex, with longer names and structures, it becomes very difficult to read the output in a table. Like most other test runners, this REALLY should display as a tree, not a table. Allow the display to be extended with test specific visualizations.

3. Stop doing test deployment when tests are run in the IDE. Deployment makes sense when run as part of an automated build process using continuous integration, but when I'm using the IDE I'm practicing TDD/BDD and deployment wastes disk space and precious time.

Nearly anything else that I or anyone else wants can be trivially built on top of what exists, given these changes. That means nothing else should be on the vNext list. On the vNext++ list you can get back to innovating, possibly with further data driven, UI automation, asynchronous testing, etc. test types.

I can go into specifics of any of this. Just contact me.