It’s time for a working code example.
The example was implemented in Python and the main goal was to demonstrate the concept of using all model’s components as presented in the article.
In the example I implemented login test:
— Login to the system with several different users — some legal and some illegal.
The test working on demo web site for automation’s developers: https://www.saucedemo.com/
Before reading the detailed example play with the simple web site and read again the article.
Project structure
As you can see we have five main folders:
1. Views — The only layer that contains locators, using the inspector layer. This layer also doing basic actions (click, type and so on) and assertions.
2. Components — A completely logical layer that addresses only the relevant view. Events published only from this layer
3. Tests — No need to expand
4. Inspector — Responsible for searching elements with Selenium
5. ViewModel — Save the current status of the system , used by the view layer fot doing assertions
Login test
One test with four types of users.
We have valid\invalid users these users marked at my “DB” as valid\invalid.
First, Initiate the login component and call the login function with the relevant user.
Here we can see the implementation of login function:
- The function can receive user from test’s parameters or explicit user credentials.
- Set user and password at their fields by login_view.
- Click on login
- Publish two types of events — case of pressing login with valid user and pressing on login with invalid user
No matter what type of user the automation’s infra handled it automatically.
Login View
At the view layer we take care on set the requested credentials, click on login and assert that errors appeared in case of wrong credentials.
As you can see at the constructor subscription was made to login pressed event with invalid user.
When the login event published from component level the assertion called and search for errors at login page.
Product View
What happen if the user is valid?
Subscription for valid user in case of pressed login button was made again at the constructor.
Assertion that the main products component visible called (assert_products_visible )when the event published from component level (login component).
Because it’s a mirror of the UUT we also init the current products as that appeared on the screen after login and save them on the ViewModel layer:
Products().add_product(product_list)
Implementation of the Products view model:
It’s a singleton, why? in order to mirror the current status of the system.
We can save the current available products on the main screen and save the selected products (that were added or removed to the cart).
Again , it’s a mirror of UUT (unit under test) — when we are doing a valid login the products page initialized with all of the relevant data, same on the automation’s infra.
The Products view model will be used at my second example of test — add or remove products from cart.
Finally the results, is it make sense?
Second test — try to login with invalid user but at QA’s “DB” it was marked as valid user — the event handler search for product component at main screen but didn’t find.
Third test — try to login with valid user but at QA’s “DB” it was marked as invalid user — the event handler search for errors at login component but didn’t find.
The goal of this two test’s parameters is to demonstrate failed login process.
Curious? stay tuned.
At meanwhile take a look again at the following diagram and see if you completely understood the concept:
Interested in an additional information or advice before the next example (more complicated test)?
