![](/assets/images/methodology/s4t_methodology_key-success-factors.png)
![](/assets/images/methodology/s4t_methodology_architecture.png)
![](/assets/images/methodology/s4t_methodology_end-to-end-testing.png)
![](/assets/images/methodology/s4t_methodology_change-your-mind.png)
Concrete implementation in ohrm-tests github repository.
Implement test automation best practices with webdriver-overload.
Jobs are created in your CI/CD server (ex are jenkins, bamboo) and are responsible for :
- Scheduling executions
- Setting execution context, usually application environnement and browser
- Filtering tests to be executed
In commun implementations they are only one entity so called automated tests. Gherkin introduce a first idea of splitting tests and automaton, however the goal is provide a translator from native langage to executable code. Therefore, when we look into the code itself, we notice that tests concepts are mixed with automaton concepts.
Having a place for everything and putting everything in its place is one of the keys to achieve maintainable automated tests.
Tests concept includes
- Test objectives (what do we want to check)
- Test data (what data to use)
- Knowledge about WHAT the application can do (available features like login, create order, ...)
- Knowledge about expected results (when doing 2 + 2 we expect the result to be 4)
Automaton concept includes
- Application configuration values (ex: the environnement X has for url 'https://...')
- Application data definition (ex: an adress is made of a street number, a street name, a post code and a city name)
- Knowledge about the elements of the application to interact with (ex: input fieds, button, ...)
- Knowledge about HOW to interact with the elements of the application (ex: how to select a value within a dropdown list)
- Knowledge about HOW to perform features (ex with login: For the data we need a user name and a password. On the action side, we set the username, then the password and then click the connection button)
![](/assets/images/interactions_pattern_01_init.png)
The test initialisation phase includes everything that must be prepared before running the test. The job indicates what should be done and the test prepare everything. Test only need the automaton to get the configuration value of the application for the environnement set by the job.
![](/assets/images/interactions_pattern_02_action.png)
A test action consists of asking the applicaton to do something (more or less create and update data, persistant or not).
When using cucumber, test is made of two parts, gherkin (tests described on natural langage) and the glue. Actions are identified using 'Given' and 'When' key words. The glue step corresponding to these phrasing looks like :
- Prepare the input data to be used to perform features in the application, using the automaton data definition
- Ask the automaton to perform one or several features (ex: navigate to a certain page, select user creation and fill user form)
- Optionaly, save some application output to be used later (get ID of user newly created)
The automaton takes care of all interactions with the application and it is made of :
- Locators : location of the application elements to interact with
- forms : All functional behavior of the application (includes navigation, fill forms, get data)
- WebDriver Interactions : Everything about technical behaviour of the application (how to click a button, how to wait on something, ...)
![](/assets/images/interactions_pattern_03_check.png)
A test check consists of comparing a result provided by the application to an expected value
When using cucumber, checks are identified using 'Then' key word. The glue step corresponding to these phrasing looks like :
- Optionaly, doing some navigation in the application and getting values (we may have save necessary output in an earlier step)
- Compare actual value (it is the value provided by the application) to the expected value (it is the value provided by the test data)
Getting values from the application includes same flow as performing features with the difference that data in the application is not created or updated, only read.
This concept implies that automaton knows nothing about expected values and checks. Expected values and checks are test concepts and happen in test.
![](/assets/images/interactions_pattern_04_close.png)
Test closure consists of compiling tests results to prepare test report, releasing and cleaning everything that is required and pushing results to the job.
Jobs remaing accesible by project team in order to access reports and analyze results.