We have started using TestCafe recently and prepared a best practices document for our test automation engineers. I just thought of sharing the content from the documentation with the community.
The following 17 best practices were captured through the test cafe online documentation, test automation scripting best practices, and our experience with similar automation projects.
- Use page objects
- Use helpers
- Use configuration files
- Use of proper file structure
- Use of naming convention
- Formatting the test scripts
- Use test script recorder
- Use of locator strategy
- Filtering tests
- Grouping the tests
- Use TestCafe Studio
- Use roles for login
- Speedup the test execution
- Use before and after hooks
- Increasing the assertion timeout
- Create data-driven tests (DDT)
- Find the code issues with Flow
1. Use Page Objects
Use a page model design pattern for separating the UI layer (page structure) from the testing layer (test logic). All the elements and actions (methods) should be defined in separate page objects. The test scripts should call the actions in the page objects to perform the desired actions in test cases. Assertions should be included in the test scripts only.
Menu items should be grouped into pages. All the page objects should be placed in the page_model folder.
The page objects should be optimized by creating and exporting an instance of the page model class.
References: link 1,
2. Use helpers
The helper functions should be extracted from reusable test code. The dynamic test data required for the testing (e.g. firstName, CRN numbers, mobile numbers etc.) should be created as helper functions.
The helper functions should be grouped into separate files. All the helper files should be grouped into the helpers folder.
Available free utilities should be elevated for generating random test data. Custom Utilities should be created for unique data and other requirements. TestCafe ClientFunctions can be used for extracting the information from the client side.
3. Use configuration files
All common test configurations (launch settings) should be defined in the .testcaferc.json file (or .testcafe.js). The file should be created in the project’s root directory.
All default configurations used for frequent test execution should be defined in the file.
Optional configurations should be defined with possible parameters/values. Optional configurations should be commented out to avoid conflicts. Documentations shall be added with comments.
Reference: Link 1, Sample configuration file
4. Project structure
Test scripts should be grouped by the test modules. Page objects should be grouped into the page_model folder. Helpers and roles should be grouped into the helpers and roles folders. Test data used for data-driven testing should be grouped into the data folder.
The docs folder will contain the test plans, test cases and other documents used for test management.
References: link 1,
5. Naming Convention
| Style | Category |
| UpperCamelCase | class/interface/enum |
| lowerCamelCase | variable / parameter/function/method/property / module alias/ file names |
| CONSTANT_CASE | global constant values, including enum values |
Names must be descriptive and clear to a new reader. Do not use ambiguous or unfamiliar abbreviations to readers outside your project, and do not abbreviate by deleting letters within a word.
Paths to test data files, config files and imports: Code should use relative paths and should be shorter (limit the steps)
Testers are advised to read Google TypeScript style guide for details.
fixtureName: All the fixtures should have a descriptive name describing the logically grouped tests included in the fixture.
testName: All the tests should have a name with a test case ID and test summary. Test case ID and the summary should be taken from the existing manual test cases.
Use the following postfix to the variable names of the page elements
| Element Type | Postfix |
| Input/TextArea | Input (e.g usernameInput ) |
| Button | Button (e.g. loginButton) |
| Label | Label (e.g errorLabel) |
| Hyperlink | Link (e.g. homePageLink) |
| Select/List | List (e.g. familyList ) |
| option | Option (e.g. firstOption) |
A few frequently used elements are listed in the above table. We shall Update the table as the project progresses.
6. Formatting the test scripts
Use the formatter integrated with the TestCafe Studio frequently to ensure the code is formatted for consistency and readability.
Variables and functions should be grouped logically. Line spacing should be added between the variable groups and the functions.
Semicolons: Use semicolons at the end of every statement
Single Quotes: Use single quotes for the string unless escaping
You should check the code visually before pushing the code to the Git version control system. The code should be manually formatted if required.
Integrate the prettier formatter into VS Code and set it as the default formatter
Spelling should be checked and corrected before pushing the code to the repository
7. Use of test script recorder
A Codeless Test script recorder in TestCafe Studio shall create the initial steps over the manual test scripting.
The element locators should be updated to ensure the locators are resilient, readable and shorter.
Assertions can be configured with the GUI. Once the basic steps are completed, the codeless script should be converted into JavaScript and, later, TypeScript.
Page Objects should be extracted from the test scripts and ensure the test logic is separated from the page structure.
The recorder shall be used for handling the native browser dialogues.
You can read more about when to use the recording in the official blog.
8. Use of locator strategy
TestCafe uses Selectors for locating the elements.
Ensure the locator used for elements are resilient to the UI changes, readable to the other testers and shorter in length. The following extracted from TestCafe guidelines explain the requirements further.
- The selectors should not be too specific.
- The selectors should not be too generic.
- The selectors should not rely on the element parameters that might change
- The selectors should be easy to understand by others
- The selectors should reflect the user’s point of view
All the selectors must be grouped into the page objects to improve resilience and remove redundancy.
We will have to work with the development team to include custom attributes (e.g. data-tested). The custom attributes will not be changed, and the code will be highly maintainable.
We shall use selectors extension plugins available for the JavaScript framework if required.
You can read more about this from the TestCafe blog.
9. Filtering tests
Include the Metadata into the fixtures and tests to filter the test execution. This will enable us to run the smoke, regression and module-specific tests on demand by including the filtering in the .testcaferc.json configuration file.
Running tests with specific metadata
Running fixtures with specific metadata
Test.skip method, Test.only method, Fixture.skip method, and Fixture.only method should NOT be used for filtering the tests. The filtering should be controlled from the .testcaferc.conf file.
10. Grouping the tests
All the tests that can be grouped logically should be grouped into a separate fixture. One fixture file should contain only one fixture. For example, all the authentication tests should go into a separate fixture file.
11. Use TestCafe Studio
TestCafe studio comes with
- Feature complete code editor
- The visual test script recorder
- Powerful Test debugger
- Smart Element Selectors
- Has built-in support for TypeScript and ES6
It is recommended to use TestCafe studio for test scripting, considering the productivity gains over the manual test scripting through other editors (e.g. VS Code)
12. Use roles for login
Use Roles for user logins. Different roles with the user login process shall be created in a separate file. The user credentials should be defined in the configuration file (.testcaferc.json file). Activate the roles from the beforeTest hook.
The roles helper file should be located in the roles folder.
Activate the anonymous user role to clear the authentication data and log out the user.
13. Speedup the test execution
We can use the following to increase the test execution speed to reduce the total execution time.
- Set the concurrency in .testcaferc.json to run multiple browsers simultaneously.
- Run tests in headless mode for chrome and edge
- Use roles for user login
- Set the test speed to default (1 is the fastest)
- Run tests in local browsers
- Optimize the page objects by exporting an instance in the page model
- Enable the server-side caching by setting the configuration in .testcaferc.json
14. Before and After hooks
You can use the beforeTest, afterTest, beforeEach fixture and afterEach fixture hooks for Setup and TearDown operations.
Use before and beforeEach for setting the prerequisites.
Use after and afterEach for cleaning the environment.
Use before and after hooks to set a state required for each test
Use beforeEach and afterEach to set a common state required by all the tests in a fixture
15. Increasing the assertion timeouts
Set the timeout values for individual assertion statements as an option if you want to wait more time to get the required state. Do not set higher assertion timeout values globally in the configuration file.
16. Create data-driven tests
Identify the test cases with the same steps but with different input data and expected outcomes. The data required for the test can be created in CSV or JSON files. The test can be executed for each data item stored in the test data file. All test data files should be located in the data folder.
See the documentation
17. Find the code issues with Flow
You can find the code issues with Flow. Correct the code issues before pushing the code to Git Repository. Integration process.
18. Use TypeScript
TestCafe supports Javascript, TypeScript and CoffeeScript out of the box. We shall use TypeScript over Javascript, considering its advantages. Incorporate the true power of TypeScript into the automation framework to make things easier.
19. Use live mode to run the tests automatically
We can run the test automatically after every save by enabling the live mode. You may have to disable the auto-save in VS code to avoid unnecessary test runs.
testcafe chrome logintest.ts -L
20. Use of third-party libraries
TestCafe is a first-class citizen in the Node.js ecosystem. Hence we can integrate third-party libraries easily.
- Random data generation
- Random dates generation
- Logging
- Test reporting
- Video recording
- Email integrations
Once the libraries are installed, they can easily be used within the scripts.
Author: Janesh Kodikara
Performance Tester | JMeter Trainer | Software Testing Service Provider
Comments