The Chandler team created functional and performance tests first by hand, and later by building an event recording and playback functionality. Chandler is built with wxPython, so what was recorded and played back were wxPython events. Theoretically you could take that system (or at least the idea) and bolt it into some other wxPython application.
Sounds interesting - but I'm not convinced (prima facie) by event recording and playback. It *sounds* fragile to changes in layout / timing etc - and doesn't provide some of the advantages of user stories. (I don't like the record / replay pattern for unit testing either...)
It definitely sounds worth investigating though and could work well as part of a framework.
Actually the way the Chandler recording and playback were done was less fragile to timing issues than the manually written functional tests. It can also withstand some amount of layout changes, because the recording and playback is done more on a logical level than just recording click and move coordinates.
I think one of the problems of event playback is the recording aspect (especially on Windows) - programmatically you could modify a test without having to re-record the whole thing. And I wonder how flexible it would really be (depending on underlying Win32 Wnd classes) if your GUI framework abstracted the controls in your app. If, for instance, your framework did custom drawing for all controls the only identifier would be the Hwnd of the top-level window and the position of say, a click - which is where that fragility you mentioned rears its ugly head again.
I actually saw the talk, and think it is probably the best compromise to flexibility whilst still fulfilling the requirements. Having said that, had you considered logging the events through overriding a WndProc at the top level purely to determine coverage (all controls are exercised etc)?
Chandler is built with wxPython, so what was recorded and played back were wxPython events. Theoretically you could take that system (or at least the idea) and bolt it into some other wxPython application.
Great article!
I will have to read more about threads and threading to understand why you run you application in STA thread and what is dangerous about my way. Also asynchronous executing looks interesting. I did not need it probably only because I use different threading mode.
Hello Lukas,
We run the application in an STA thread because Windows Forms *requires* it. What is your way?
Michael
My way is described on
http://gui-at.blogspot.com/2008/...onpython-
2.html
My friend adviced me this way. It seems to work but I don't know whether it is the correct way.
Ah, I didn't recognise your name Lukas. I've been following your blog with interest.
If it works then your call to 'ThreadPool.QueueUserWorkItem' is probably launching an STA thread anyway.
On the other hand, the only reason I use 'my technique' is because that is the way I have always done it (and it works). The MSDN docs do state that Winforms apps require an STA thread though - I've no idea how rigidly that is enforced or what point you can expect things to fall apart if you start them in an MTA thread.
So do I your blog 
I will try to more investigate threading and if I find something, I'll post it on my blog.
Commenting by HaloScan
