Well I finally managed it. (well 80% of it!).
What am I talking about? 'Application data' where you save information from one run of an automated GUI run and use that information next time to work with changed software (in my case Translated to a different spoken language!).
There is still one small part that I want to implement before I release a 0.3.0 release. Currently it works for dialogs, controls and menu's - but I still need to implement looking up appdata for selecting items in controls (listboxes, treeviews, etc)
The implementation is very basic - and certain things will not work without some form of user override (e.g. selecting the correct item in a sorted listbox/combobox). Unfortunately there is no override available (but I think I will need to look into that soon).
The internal handling of appdata may well change (almost certainly) - but there is very little that a user uses at the moment - so not a big impact I think!
This code does not affect normal operation - so I am not worried about this code causing regressions in the normal use case if just automating a GUI.
So for now I feel I have a working proof of concept - but I think I need to put more work into making it a robust, workable solution.
What's the relationship with winGUIAuto? Seems like this is re-inventing the wheel, although I kind of like the 'shape' of the wheel a bit better :-).
ReplyDeleteOne thing that I would like to see is a template system for matching window state, and an XPath-like syntax for referenceing controls in dialogs. XML could be used to show what the expected state is - it's heirarchical, just like the windows themselves. I guess first thing to do would be to 'dump' the state to XML, then edit it to remove stuff that can take any value, then have a comparison function. Am I making any sense? I'm also very interested in the i18n issues of testing.
I looked at winGuiAuto - which later got merged into watsup. But I didn't like the way they worked. They were also doing a very minimal subset of controls - so I didn't feel bad re-inventing this particular Python wheel at all :-).
ReplyDeleteI already have an XML format - but it is not so important for pywinauto (more for another project that shares code with pywinauto).
But I see no need for XML if you just want to match a control - it's all in memory anyway :-)
Either way - it doesn't sound like something that I am going to give priority to. Now that I have finally implemented the i18n feature - I can see how it doesn't work more clearly - so I need to get my head around that (which unfortunately is not an easy thing).
I will probably wait a release or two - focus on testing and coverage again for a little bit, and just general code cleanup.
I will be hosting my Subversion repository somewhere on the internet - so other's can contribute if they so desire.
I wasn't just thinking of using XML for matching a control, but also for matching a dialog state in detail with an expected state. While running through a test case for the first time, one would record a series of XML 'snapshots'. On subsequent execution, the generated snapshots would be compared with the reference snapshots, and you'd decide if the result was as expected. I felt this would have an advantage because the comparison function then becomes nothing to do with pywinauto, also, it can ignore the language-dependent bits or include them depending on the nature of the test, one could even use schemas to determine if the test had passed.
ReplyDeleteIt doesn't really matter if you are planning on working on this. Using the introspection it's possible to layer this on top of what you've already got.
I just like the idea of an approach where I 'record' some expected states, then hand-edit them to meet my requirements about what can change and what shouldn't.
I suppose it depends how you want to store the data relating to pass/fail of tests. Whether that should be code, or data-driven. both approaches have their drawbacks, of course.
I have already written code to compare dialog dumps from resource dlls of different language, to ensure that things like tab-order are consistent between the two and I see extending this to run-time instances as being essential for proper localisation testing.
I suggest we move this to email :-)
ReplyDeleteI can give you suggestions for that. In fact pywinauto's first incarnation was nothing but a set of modules for doing localization testing - you don't need most of pywinauto for that. pywinauto is more for driving the GUI - and that is MUCH harder to get right :-)
Handy if I give my mail address - mark (dot) m (dot) mcmahon (at) gmail.com
ReplyDelete