several design patterns
Linear mode
I call it code, that is, direct hard code according to business logic. Basically, beginners will toss like this. Of course, after tossing for a while, they will feel very fucked, and they don't want to read the code they wrote.
Page Object
The more popular design pattern is highly decoupled, and beginners may feel a little bit fucked, but after understanding the logic, you will find that this is very good, and it is easy and pleasant to maintain.
General framework
The general framework is a relatively advanced practice, and it is more troublesome to implement. If the level is reached, this method is definitely the best. Using keywords to drive the program is a relatively advanced state. The disadvantage is that it is more difficult. . . .
Design ideas
The whole design idea is based on the Page Object mode, as shown below:
What is a Page Object?
When you write tests against a web page, you need to refer to elements within that web page in order to click links and determine what’s displayed. However, if you write tests that manipulate the HTML elements directly your tests will be brittle to changes in the UI. A page object wraps an HTML page, or fragment, with an application-specific API, allowing you to manipulate page elements without digging around in the HTML.
It turned out to be a web-side model. Moving to the mobile side is to split the page into elements one by one. As shown in the schematic diagram, I split it into such things as element data, element positioning, element operation, and test steps.
what is the benefit?
The whole architecture of this mode seems to be much more complicated than the direct coding, but when encountering some pitfalls, especially when the development changes frequently, the advantages of this design mode come out, such as the IDs of the elements that have been changed in the development. Then we just need to modify the corresponding ID. All the elements related to this element are directly related and modified, and directly swiping the code may involve a lot of places, which is very troublesome to change. There is no need to change the search method, test steps or anything, and it is relatively easy to maintain.
Project structure:
____.DS_Store
|____config.py
|____Data
| |____data.json
|____img
| |____.DS_Store | |____caixun | | |____gupiao.png | | |____gupiaoneirong.png | | |____jijin.png | | |____jijinneirong.png | | |____tuijian.png | | |____tuijianneirong.png | | |____xinsanban.png | | |____xinsanbanneirong.png | | |____zhaiquan.png | | |____zhaiquanneirong.png | | |____黄金.png |____Report |____test.py |____TestCase | |______init__.py | |____common.py | |____testCaixun.py |____View | |______init__.py | |______init__.pyc | |____BaseTestCase.py | |____BaseView.py | |____Caixun.pyI divided the big directory like this:
- Data is used to place some data
- Report Store the test report
- TestCase stores test cases
- img to store some screenshots
- config.py configuration file