Skip to content

README.md

Latest commit

 

History

History
72 lines (57 loc) · 4.5 KB

README.md

File metadata and controls

72 lines (57 loc) · 4.5 KB
Showcase.mp4

The e2e tests follow this architecture:

Architecture of e2e tests. It shows how a Test uses Actions, which in turn uses from 1 up to several Drivers

  • Test: a test case itself, which has the executable specifications.
  • Actions: a set of actions that the user (thus the automated test) can perform on the application. By extension, they have a business relevance. Each action may orchestrate different steps by using a Driver. Examples of actions may be login or add item to the shopping cart.
  • Driver: the low level technological automation that actually knows how to perform the different actions. It has the knowledge of how to find a certain element. Examples of steps perform by a Driver: find the InputBox for the username, write the given text, find the InputBox for the password or click on the login button.

While currently the Tests just use a single Action due to the app simplicity, this allows for using different ones to automate different applications or decompose one into different modules (e.g. user profile actions, project tree structure actions, etc.). Also, by having the Actions and Driver separated, changes in the technological spectrum such as a Button changing its id or location or a Label its text does not cascade into the business Actions (unless the workflow has actually changed).

I don't remember if this 3-layer architecture style for e2e tests has been already defined and name by any other person before, but it has been inspired for sure by both the Page Object pattern and Dave Farley in How to Write Acceptance Tests - Modern Software Engineering .

Decisions

  • Usage of accessibility ids.
    • Pros:
      • More robustness, since its purpose is exactly serve as an automation reference and is not subject to change as the value, internal name or class may change for other reasons.
      • Also, pretty much the reasons mentioned here.
    • Cons:
      • The production code is polluted just for testing reasons.
      • It cannot be used in dynamically generated elements (e.g. elements in a list). This forces to use another location strategies, thus making the code less homogeneous.
  • Attach the drivers to specific windows.
    • Pros:
      • Easier to find elements by faster & more precise locator strategies (e.g. by accessibility ids, by class name, etc.) rather than relying on XPath.
    • Cons:
      • Tests implementation is coupled to which windows the app opens: if a form is now embedded and previously was a window on its own, the test will fail to locate its element and will need adaptative changes.
  • Splitting the execution of e2e tests from the rest. In the CI, the e2e tests are executed separately from the rest due to their specific requirements. To do so, any namespace that contains e2e are excluded from the common test runs. This is a quick approach, but relies on following the convention of naming the e2e namespaces with e2e. Another approach would be to use different csproj or test annotations; relying on the namespace has been chosen for convenience giving up flexibility and a better separation of concerns.

How to run these e2e tests

Prerequisites

These tests use Appium as the automation framework.

For instructions in how to install everything, refer to:

Good to know

Since Appium (WinAppDriver, really) relies on what Windows exposes in its automation layer, it's precisely useful to know how to inspect what Windows exposes in order to use it to automate these kind of tests.

Check Inspect.exe for this matter.