Tips to make your (web) application testable

This blog post 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.

  1. Unique identifiers
    Especially when doing UI testing, it’s important to have unique identifiers on the page. There are different approaches: assign an `id` to every element or assign a 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 they can search relatively within that component. Like, you have a search component with an 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:
    section#search
    input[name='query']
    button[name='search']

    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:

    .//*[@id='wx-header-wrap']/div/div/div/div[2]/div[2]/div/section/div/form/input

    or

    .//*[@id='gnav-header-inner']/div/ul/li[2]/a

    The first is too long and therefor unreadable. The latter is much shorter but is tightly coupled to the second list-item (li[2])

  2. Separate environment
    Once, I was on 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 huge Ora cle database. Cost-saving is fine, but it had some drawbacks.

    • Different testers/teams are manipulating 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.

  3. Mock third-party services
    When testing in general, depending on data which is outside of your control and 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).

Share This: