Web Testing in General¶
Web testing is quite simple. This is mostly because of open standards, and excellent tools (such as Selenium on which this project is based). Because it is so simple, it is also real easy to get yourself into a maintenance nightmare. This document will hopefully help you to get started in a way that will make things easy to grow and maintain.
To do web testing using this library you are going to want:
- A Browser, Firefox is one of the easiest to get started with selenium.
- Python (I assume you have this or why else are you looking at this?)
- This library installed into python (use pip to install it)
- Nose though technically you can test with the builtin unittest module, nose makes running the tests easier.
There are several things you will want to do to help you scale your testing from a couple of tests here and there to hundreds, possibly even thousands of tests. Below are suggestions, the framework does not restrict you to following them, but they will help.
- Put your page classes in a separate place from your tests. Make sure they are usable from multiple sets of tests, even if you don’t have multiple sets of tests yet. See Page Classes.
- Don’t put assertions in your page classes / framework code. Assertions belong in tests, not framework.
- Don’t try to model everything your product does, model what you need for your test. Spend time working on tests, the framework is just part of the test that has to be written for efficiency reasons (sharing code).
- Group your tests, and keep track of meta-data (however your framework chooses to do so). It’ll come in handy when you need it later.
- Make your locators and page classes as simple as possible, this simpler it is, the easier it is to maintain.
- Don’t use record / playback tools, they create horrific unmaintainable code!
- Browser dev tools are great for helping you to inspect elements to automate.
- Make sure your tests read well, your test should look like a list of actions and assertions. If you have a lot of boilerplate code, consider refactoring.
The process for writing tests involves working with 2 different types of code: page classes and framework, and test code. You can easily write both at the same time. Here is the typical workflow I do for writing a test:
- Write the code (or reuse the code) to launch the browser, and manually open the browser.
- Go to the URL in the browser, and once again, write the code to go to the correct url.
- Go through any other setup procedure manually, and make sure you have code to match. This is an excellent place for framework code, reusable setup code (like logging in).
- Look for the first web action to do, inspect the element. Your looking for something that uniquely identifies the element. An id is the easiest, but they are not always there, especially on repeated elements. For forms, names can usually identify the elements. As soon as you find what identifies it, create or add it to a page class. See Page Classes and Locators for more details.
- Keep adding code to exercise the web site, but look for places where you need to assert that things are progressing. Don’t be afraid to add assertions in the middle, make sure every step works properly.
I think that writing the automation, while manually executing the test is the easiest way to create a good test. However, with this method you need to watch out for where it would break, or show errors when it’s not working. You might need to look for elements that are there to display errors and assert that they are empty.
Tests should be readable and easy to understand. If you notice you are repeating yourself a lot, or your tests are confusing, stop and fix it!