core-web-rendering-templates-ui-tests v0.0.1

Core Web Rendering Tests

This is end to end (e2e) testing framework based on Cucumber + Puppeteer

Prerequisites

• node >= 10.15.0 < 12.0.1
• IDE to edit Features and Steps
• GIT

Screenshots Pathes

Check out .env.default file in root. Change SCREENSHOTS_PATH, FAILED_SCREENSHOTS_PATH, RUNTIME_ERROR_FILE_PATH according to your file- system

Installations

 npm run preinstall

For Windows OS install GIT Bash and change Shell path in Webstorm settings. \ File -> Settings -> Tools -> Terminal \ Win64bit: "C:\Program Files\Git\bin\sh.exe" --login -i \ Win32bit: "C:\Program Files (x86)\Git\bin\sh.exe" --login -i

Run tests

Run all tests across the framework:

 npm run test 

Windows OS:

 npm run test:win

Run some specific test:

 npm run test -- ./fetures/smoke/Form.feture

Windows OS:

 npm run test:win -- ./fetures/smoke/Form.feture

Configurations

All configurations of the app is located in ./env file. Before you start (and if pre-install command is failed or wasn't run) please create folders from your screenshots, otherwise test will fail. Available configurations:

BASE_URL - Default url to start browser HEADLESS - headless mode (Could be used for CI) IS_DEVICE - device or usual browser DEVICE - name of device, for example 'iPhone X' BROWSER_WIDTH - browser width BROWSER_HEIGHT - browser height SCREENSHOTS_PATH - path to screenshots folder (folder should be created manually) FAILED_SCREENSHOTS_PATH - path to failed screenshots folder (folder should be created manually) SCREENSHOT_FAILURE_THRESHOLD - allowed percentage of screenshot comparison mismatch TIMEOUT - timeout, used for all wait commands RUNTIME_ERROR_FILE_PATH - path to runtime error log. If it's specified all errors would writte on file otherwise in console ERROR_STRICT_MODE - stop test execution on error immediately

TQuery

To make testing more behavioural and predictable we developed small query language TQuery (abbr. for Test query). It applies a few simple rules:

1. All queries start from capital letter, e.g. 'Article Module'
2. Nesting elements could be retrieved via -> sign, e.g. 'Article Module -> Headline -> Image'
3. If there are a few elements matching a query, first would be selected.
4. If you want to retrieve e.g. 3-th element, just write a number of it in brackets. 'Carousel -> Slide 3'
5. So how corebine have stable css class naming we can use special constructions to use it. Important: type token should go after module name. Token is case sensitive. E.g. 'Atricle Module' would be converted to '.m-article'. Available types:
   • Module. Example 'Article module' -> '.m-article'
   • Component. Example: 'Image Component' -> '.c-image'
   • Block. Example: 'Ad Block' -> '.b-ad'
   • Section. Example: 'Gallery Section' -> '.s-gallery'

To retrieve Image element you should write following query 'Article Module -> Headline -> Image'.

Note: tQuery applied across all framework where we can apply css selectors. For example:

I click on 'Article Module -> Headline -> Image' element

Be aware css selectors still work like a charm,

I click on '.m-article .s-article-headline .s-article-headline-image' element

One more note: if you want to apply css selector for article tag, just write it as it is using lower case:

I click on 'article div > span' element

All tQuery tokens would be converted to real css query according following rules:

1. Check reserved words (fifth rule in TQuery section above).
2. Check page objects.
3. Convert into data-test attributes.

If our token is not tQuery token (doesn't start with capital letter) it would be handle like a simple css selector.

Data attributes

In case to follow BDD paradigm and prevent tests broke after any css selector would be changed it's recommended to use data-test attributes. They are not tied to implementation and gives some persistency to css selectors changing. Important: IF YOU USE TQUERY BE SURE THAT HTML MARKUP OF TESTED PAGE HAS DATA TEST ATTRIBUTES.

Page objects

tQuery could works with page objects - description of entities (like module, component and other) which maps names to css selectors. Page objects have hierarchical structure. Page objects description files are located here: spec/page-objects. Page objects could help when developers cannot drill their data-attributes to third-party modules.

Example:

'Navigation Search Dialog': {
        selector: '.g-dialog-container',
        children: {
            Input: {
                selector: '.s-navigation-search-modal__input'
            },
            Button: {
                selector: '.s-navigation-search-modal__button'
            }
        }
    } 

So how QA specialist doesn't know how developer named module and its components we have special description file: page-objects.md. It must be generated automatically via our special utility. To run it:

npm run pod:create

Main workflow for developer:

1. Integrate third-party module\component etc
2. Create appropriate page object. a. Go to spec/page-objects/ folder and create a file with appropriate folder (module, component, etc) b. Create module\component description: Add module itself and all its children. c. Add new module to spec/page-objects/index.js
3. Test your binding with some demo test in features/demo/...
4. Run npm run pod:create to update page-objects.md

Errors

By default we had enabled browser errors observation. That means all JS, Network and other errors which occurred during execution would be logged in file or console (depends on configuration). Strict mode could be used to stop test execution after any error is occurred. Developers could use it in local flow to catch any problems with their current changes. To enable log into file you have to specify the path in following config:

.env:

RUNTIME_ERROR_FILE_PATH = /Path/To/Your/Project/And/File.log