This blogpost will provide you some tips to make your (web) applications better testable. This is an initial list of tips and can be extended of course. The idea is that you can use this list when you have discussions with your developers about testability.
- Unique identifiers
Especially when doing UI testing, its important to have unique identifiers on the page. There are different approaches: assign an `id` to every element or assign an unique identifier to each component and input element.
Implementing id’s for every element is costly and unnecessary.
Implementing unique identifiers for every component is a better approach, because the can search relatively within that component. Like, you have a search component with a input field and button:
<section id="search"> <input type="text" name="query"> <button type="submit" name="search">Buscar</button> <section>
Now you can construct the following CSS locators:
Although it’s not needed, I’m in favor of defining the type of the element.
When not having these unique identifiers you will probably end up with very hard to maintain locators. A few examples:
The first is too long and therefor unreadable. The latter is much shorter but is tightly coupled to the second list-item (li)
- Separate environment
Once, I was in a project where the test-database was shared with multiple test environments. I believe this was done to save some costs, as we depend on a very huge O racle database. Cost-saving is fine, but it had some drawbacks.
- Different testers/teams are manipulation the same data;
- Different versions of software are processing the same data;
- Different message-consumers are messing with the data.
This was not very convenient and after some debate we found the budget to duplicate the environment (including database and all services). The result was an isolated environment for running our automated tests.
- Mock third-party services
When testing in general, depending on data which is outside of your control an become a nightmare. Because of the following:
- Third-party service can decide to switch-off the servers;
- Third-party service can decide to clean the (test) database, so the data is not present anymore;
- Third-party dataset is very limited.
You might decide to stub/mock the third-party services, if you recognize one/some of the above. When stubbing/mocking third-party services you have full control over the data and you can even easily simulate error-responses/timeouts/etc.
It would be great to hear your tip, so I can add them to the list. Feel free to leave a reply (tip + argument and in what situation did you benefit from it).