避免在Python中使用非Python或无法维护的GUI测试结构

Question

I am starting a new Python project that will wrap generic GUI testing functionality (developed externally, eg Sikuli) into an application specific framework. The aim is to make writing test scripts for the application as simple as possible, including reporting test results and handling errors.

There are many approaches possible, and none seem ideal, however I am very new to Python so there could be something simple yet effective that I am missing. Essentially I am trying to balance clean __init__.py files, ease of use and maintainable structure.

As an example, I would like the script writer to be able to write something like this:

import framework
import framework.programs.program_f as curr_program
import framework.pages.page_b.area_a as curr_area

if __name__ == "__main__":
    framework.log.start_section("Section 1")

    curr_area.click_button(curr_area.buttons.BUTTON_D)
    curr_program.wait_for_launch()
    curr_program.test_is_running()

    framework.log.end_section()

So, no need for them to create instances of objects (even though I can use objects in the background). However, this layout requires object instances to be created in the package __init__.py files, eg:

|- framework
|   |- log.py
|
|- pages
|   |- page_a
|   |   |- _areas.py (contains class AreaA(AreaBase): ...)
|   |   |- dialogs
|   |   |   |- __init__.py
|   |   |- __init__.py (contains area_a = _areas.AreaA())
|   |
|   |- page_b
|   |- __init__.py
|
|- __init__.py

The alternative is to provide the test writer with classes and rely on the tester to use them sensibly (eg only creating one instance). However, with a package for each page (to keep page-specific files well organised) and a desire to keep __init__.py files mostly empty it could easily result in the need for code like this:

curr_page = framework.pages.page_a_pkg.page_a_mod.PageA()
intro_page = framework.pages.intro.intro.Intro()

rather than my original:

curr_page = framework.pages.page_a
intro_page = framework.pages.intro

The first feels unPythonic because of the deep nesting, and repetition. The second feels unPythonic because I am masking the use of objects. I cannot see a third way, and think this may be due to my inexperience with Python.

Are there any adjustments or alternatives that suit this problem? Or even, am I approaching this problem in the wrong way?

Edited to add:

A third option would be to use a structure like:

framework
|   |- pages
|   |   |- page_a_mod.py
|   |   |- _page_a_pkg
|   |   |   |- page_a-specific stuff
|   |   |   |- __init__.py

But that just turns page_a_mod.py into an extra __init__.py file for _page_a_pkg , but under a different name. Same result, just moving the deck chairs around a bit.

Answer 1

While personally, I think there's value in having people achieve at least a baseline level of familiarity with the language and your framework's API so they can be truly effective, you could use one or more context managers to act as a sort of setup state-machine that then drops them in to a context with some already created objects ready for them to use. Then they could do something like:

with test_context('new_user', 'logged_in') as context:

    context.current_area.click_button(....

Though I'd suggest you also look at using a proper unit testing framework, like pyunit or nose , to drive your test scenarios.