General Style
- The tests should use Domain Specific Language and have no knowledge of the underlying implementation, ie, no knowledge of the HTML, no refs to tags. Where necessary logic should be written in Pages to locate elements based on business keys
- Test should cover Business Functionality and User Experience, i.e. should perform page interaction as well as checking results
- Consider OO language for the tests so that we can lever the power of encapsulation, inheritance (e..g for common page elements such as headers) and polymorphism (e.g. for reducing custom code)
- Build reporting into the framework and include screenshot taking.
- Consider using a BDD tool to provide Acceptance Test Coverage
- Apply the Test Pyramid pattern, so focus on GUI and integration testing, and let lower-level testing (e.g. unit test) test the functionality
- Separate tests for the web mechanics and separate tests for the business functionality
- Always test the app, and never internal representations (e.g. maps)
- Reload the Page Object whenever you navigate to a new page
- Agree an html element location strategy (use of Classes and IDs) with the Devs
- Test should be able to call back-end functions such as restarting the app
- Similar apps should be tested as one app using inheritance to separate
- Get a utility to access the the server side system clock
- A framework for testing Web App functional components
- Build a Base test class for common startup and tear down and useful test utilities
- Build a Common Tests class to represent cross page tests
- Build a class per Web Page
- Build User Journey / app wide / cross pages tests classes (state transition)
- Don't make any reference to HTML
- Don't have knowledge of the HTML/Xpath
- Should be 'annotated' to allow grouping of tests
- Should support test skipping / disablement
- Create utilities to set the state for common scenarios e.g. given persona x get me to page y
- Create utilities for common sets of actions
- Test Data (hardocde) stored in one class
- When comparing Lists, compare an actual list with an expected list. Create a method taking an actual list and expected list. Ideally you compare a simple list of String where the String is a concatenation of the contents.
- Combine tests where convenient because test run time is more important then test granularity.
- Create suites to group tests into; smoke, regression, functional etc. Consider building this into the build tool scripts (whether Gradle or Ant)
- Separate tests for the web mechanics and separate tests for the business functionality
- Can have a basic 'happy path' test as a starting point and then develop 'edge cases' and 'sad paths' in separate tests
- UC/UI test use Page Classes whilst Web App functional Integration, E2E etc use Interface
Pages Classes
- Base page class for common properties (eg header, footer, quick links)
- One class per page
- One class per common fragment e.g. basket, .. may need a separate base fragment
- All elements should be final
- Methods to support UI testing
- Implements Interface to support Functional Testing
- Page flow enforced thru any element that navigates to another page to be private and check you are on right page when starting
- Use XPATH to define elements, can move to CSS Selector when there is sufficient support.
- Class to represent the browser and class to represent the app as a whole
- Web element referencing strategy agreed with the Developers. Tests need to be robust (survive html layout changes) so need to be dependent on attributes and not tags. Tests need to be able to easily locate elements so all elements required for automated testing (including the page) should be independently accessible (e.g. separate amount field from units). Unique elements should have an ID, Where multiple instances exist a Class should be used. Finally instances of elements need to be testable. Inner text can be used to test an instance of a Class but this requires control over any potential Content Management. Where Inner Text cannot be pre-determined then IDs will need to be manufactured.
- Xpath should just locate the element, and not check for text, type, position etc. Do this in the test so it is visible
- Use sub-element to join xpaths to replicate WebElement find within a find
- Utilities and enums to support the common tasks .. tests should know nothing about the HTML
- Use the appropriate data for the type of test
Interface to support Functional Testing
BDD style methods
Test Data
In an Enum
Separate stubbed from integration
Parameterised data selection
Test Automation
- Overide automation tools behaviour so that you can add behaviour which is very useful
- Factory to return browser class instance
- Good reporting, test grouping, ease of parameterising and OO support, e.g. Selenium Java and TestNG
- On error capture screenshot
