- Tests software from the user's perspective
- Makes regression easy
- Should represent exactly a specific business requirement
- Tests a lot of production code with fewer lines of testing code
- Recorded tests (not maintainable)
- A framework should interact directly with a Web Application (Actually it'll deal with selenium)
- Our tests will interact with the framework, but not with the Web Application!
- Our tests should be simple to understand (We must know what's testing)
- Let the tests drive the creation of the framework
- Workflows
- Pages
- Navigation + UI Utilities
- Selenium
- Web Automation allows us to handle a web browser programatically
- Useful for testing
- Provides an API to interact with a Web Browser
- Works on a lot of browsers using the same API!!
- Firefox
- Chrome
- Safari (OSX/MacOS)
- Internet Explorer/Edge (Windows only)
- PhantomJS
- We're humans and we can make the same task differently by mistake
- We don't want to repeat tasks that we've made succesfully in the past (regression who?)
- Testing in different browsers is boring (Yes, IE8)
- When unit testing from devs is not enough
- Complex tasks over a webpage
- When we need to test business critical processes
- Setup data
- Interact with the browser
- Check the results
It's easy to lead into the temptation of performing a lot of tasks on a single test. This should be avoided!
- Browser tasks are slow
- We need useful feedback to detect where/how/when the test target failed.
- By id
- By css selectors
- By xpath
- By classes
- By name
- By visible text (partially or totally)
- By tag
getting html elements is an expensive task. Choose your strategy wisely!!
- Send keys
- Click
- Drag & drop
- Wait (explicitly) - Performing blocking tasks on an asynchronous world -> Careful with race conditions!!
- Until an element is present
- Until title contains/is
- And more... (refer to the API)
- Wait (implicitly) for a certain period of time. DO NOT MIX IT WITH EXPLICIT WAITING!!
- Wait (Fluently) - check for a condition until a timeout is reached
There's no silver bullet for Automated Tests. Pick the one(s) that adapts to your use case.
- Tests are actions
- Users (or webdrivers :) ) perform these actions within a page
- Page is an object that knows
- their composition
- the actions that can be performed on it (from a user perspective)
- Users don't think their use cases as a set of actions performed over web components. Neither should the tests!
- If a page redesign occurs, the page object changes, but the tests (usually) don't.
- Page object methods should return values (page objects, booleans, etc.)
- Translates user actions into webdriver actions over webpages
- Readable tests: even a user can write them!
- Writable tests: no more duplicate code
- Extensible: keep the contracts alive while adding new behavior
- Mantainable
Selenium webdriver should't do all the work when data is needed. Keep it for the test execution, and create alternative methods to generate state.
- Test execution should be trackable
- Use reports to show them on a CI environment
- Tests shouldn't depend on each other
- If you need data created by another tests, mock it
- Cleanup the browser on every test :)
- CAPTCHA (Webdriver IS a robot)
- UI Tests for downloading files (get the file without using the browser action if needed)
- Check for HTTP response codes
- Third-party logins (accounts might be blocked!)
- Expecting tests to run in an specific order
- Performance testing
- Spidering