Tips to make your (web) application testable

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.

  1. 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:
    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 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.

  3. 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).

Share This:

Clean(er) Test Automation Code

This blog post tries to explain why it is important to really care about your test (automation) code and write clean (automation) code. I’m mainly involved in test automation, so some of the examples given are related to that, but most are related to programming in general. Often test automation code is less exposed to a formal review process. Keep in mind; test automation is code and should threated like that.

I hope this blog post will bring you one step closer to clean(er) code.

Test Class Naming
Defining a classname for unit testing is rather easy; it’s the same name as the implementation class. In terms of functional or integration testing, the classname should reflect the feature or functionality you are testing.

For example:

public class LoginTest { }

public class RegistrationTest { }

public class OrderTest { }

Test Method Naming
I have been on many projects, some Greenfield* others continuing development on an existing codebase. Every project has its own naming convention* or not ☺. The following can happen in projects without naming convention:

@Test
public void test1() { }

@Test
public void test2() { }

// or:

@Test
public void testLogin() { }

Do you get the point? It’s all very descriptive, isn’t it?

Imagine you have to share this with a colleague or you have to present the results to non-tech colleagues, they have no clue what’s going on.

I very much like the naming convention introduced by Roy Osherove (http://osherove.com/blog/2005/4/3/naming-standards-for-unit-tests.html). The basic idea to describe the tested method, expected input or state and the expected behaviour as the name of the test method.

public void nonExistingCredentialsGiven_ShouldThrowException() {

}

We can adopt this principle for feature testing as well.

public void nonExistingCredentialsGiven_ShouldShowErrorMessage() {

}

By following this naming convention we can make sure that the intent of the test is clear to everyone. (Off course the implementation should reflect the method name) Method names are a bit longer, but self-explanatory.

Naming of fields and local variables

Another thing that strikes me is the use of non-explicit fields or variable name. Like:

i for loops
page when applying the Page Object Model (everything is a page lol)
And so on..

We need to be more explicit if we want to create readable code.

Magic numbers
Magic numbers indicates the direct usage of a number in your code. By doing this, your code becomes less readable and harder to maintain.

Example implementing magic numbers:

public class Username {

	private String setUsername;

	public void setUsername(final String username) {
		if (username.length() > 10) {
			throw new IllegalArgumentException("username");
		}
		this.setUsername = username;
	}

}

After refactoring

public class Username {

	private static final int MAX_USERNAME_SIZE = 10;
	private String setUsername;

	public void setUsername(final String username) {
		if (username.length() > MAX_USERNAME_SIZE) {
			throw new IllegalArgumentException("username");
		}
		this.setUsername = username;
	}

}

The refactored example allows you to easily update the maximum size of a username, even if its used in different methods.

A general rule of thumb might be when applying any naming convention is to be very explicit.

Greenfield: setup a project from scratch.
Naming convention: set of rules

Other Test Naming Conventions: https://dzone.com/articles/7-popular-unit-test-naming

Share This:

Genereer Leanpub book

While writing a book (Leanpub) it might be useful to quickly replace a lot of variables in one go. Therefore I created this tool. GenerateBook-all-1.0.jar

The tool expects to following directory structure:

|-orig/ (folder containing the original files)
|-manuscript/ (if this folder does not exist it will be created)
|prop.properties (file containing all variables you want to replace)

Example prop.properties file content:
authors=Author1 and Author2
demo.url=http://example.com
software.version=12.3

Usage:
To use this tool: java -jar GenerateBook-all-1.0.jar

Example output:
Copied: orig/chapter1.md to manuscript/chapter1.md

I hope this tool is useful for you and additional features can be requested via comments.

Share This:

Use Sonar to Check the Quality of Test Automation Code

sonarsource-300x94I am working now for more than one year on a test automation project with thousands of lines of code. I started this project on my own, but during the year much more people got involved. Everyone with their own coding-style. We needed to guarantee the quality of the code written by those people. Therefore we introduced Sonar which performs static code analysis and can find violations of standards. The analysis include:

  • Coding standards;
  • Code duplication;
  • Code complexity;
  • Potential bugs;
  • Code comments;
  • Unit Test coverage;
  • And more…

Writing test automation code is like doing “normal” development. So you have to apply coding standards, patterns to avoid duplication and reduce complexity, code comments to describe what each function does. Sometimes when testing safety critical systems you have to write unit tests for the test automation code as well.

Sonar gives you insight in all those areas. It became very clear to me that some test automation developers have bad or uncommon practices. (See screenshot of the dashboard)

dashboard-300x138

Sonar gives the ability to fix or resolve those bad habits.

Installing Sonar is fairly easy

Analyzing your project is even more easy and can be done in three ways:

  • Sonar Runner
  • Ant Task
  • Maven Goal

That said, I think the first week of this year was very effective, we have taken the automation code to a higher level.

Share This:

2013 Retrospective: a year’s reflection

Just a couple of day and the year 2013 comes to its end. It’s time to look back and reflect what I have done this year. Quite a lot of things came across my path: daily work, sales meeting, testing conferences, writing articles, training people and my promotion. Yes, you read it well, I have been promoted to a different business unit: consultancy 🙂 ! (this means that I will do a bigger variety of assignments across the Netherlands) I worked for the following customers in 2013:

SpilGames Implementation of an automated testing framework using the open source stack.

Dimpact Implementation of performance testscripts to measure the server-side performance (Jmeter) as well as the client-side performance(WebDriver).

Steinweg Tool selection for a new testautomation implementation for their entire landscape. (ongoing)

Sanoma Implementation of performance testscripts to measure the server-side performance (Jmeter) as well as the client-side performance(WebDriver). (ongoing)

Hema Test Automation POC using C# / WebDriver.

Postcode loterij Test Automation implementation using Java / WebDriver.

Richard Oosterhof PHP Selenium Automation. (ongoing)

Below a list of articles I wrote in 2013:

May 2013: “Implementeren van Behaviour Driven Development” in the Spring Special of TestNet Nieuws (TestNet Nieuws 2013 – 1, page 14)

June 2013: “Behave yourself – BDD for testers” in Professional Tester (Issue 21)

June 2013: “The benefits of BDD” in Professional Tester (Volume 5: Issue 3)

September 2013: “Implement Maintainable Test Scripts by applying Design Patterns” in Software Developer”s Journal (Selenium 2 WebDriver)

Below a list of conferences I visited in 2013:

May 2013: “Het overbruggen van de communicatiekloof met Behavior Driven Development/Testing (BDD/T)” at the Spring event of TestNet (Event)

June 2013: “Structured functional automated web service testing” at Test Automation Day in Rotterdam (Event | slides)

July 2013: “Aan de slag met Selenium WebDriver” at TestNet Summerschool (Event | slides – “Aan de slag met Selenium”)

November 2013: “Getting started with Selenium WebDriver” at Software QS Tag in Nürnberg (Event)

Share This:

Test Automation Day NL 2013

Herewith a very short update. I was very glad to be part of Test Automation Day 2013 with my track on “Structured Functional Automated Web Service Testing”. I was even more pleased to be introduced by Dorothy Graham.

Please find the slides of my presentation below:


I really liked the final keynote by Emily Bache (@emilybache) with her vision on “The Future of Test Automation”. This was a very inspiring talk! She spotted two trends in our industry. The first one has to do with Lean Startup, a method for developing successful products. The second trend is towards distributed architecture, independently deployable components communicating via messages. Below you will find a quick summary photo of the keynote.

EmilyBache

I’m looking forward to the next Test Automation Day edition!

Share This:

Plans for 2013

It’s time to set some goals for the coming year, 2013.

2013-150x150

Changing work schedule
Last year we noticed that there are coming a lot of requests in the area of test automation. Therefore, my employer and myself have decided to change my work schedule. From now on, I will work 4 days at the same client and I will have 1 flexible day (which I can spend with other clients). Personally I like this change very much, because I get the ability to work in other environments as well.

Special Development Program (SDP)
A selective group of Polteq employees are selected for SDP. I’m one of them… 🙂 This consists of a curriculum of a wide scale of trainings, both soft skills and hard skills. We will spend 65 evenings together (till March 2014) to learn a lot of new things to become a better consultant. It”s a great opportunity to learn so many things in such a short period of time.

Blog
I aim for a weekly or biweekly post in 2013. Those posts will cover my experiences and things I learned on the job and in the Special Development Program. This also gives me the ability to look back and reflect what I have done and learned.

Selenium/WebDriver trainings
Also in 2013 I will work as a trainer to spread my knowledge about Selenium/WebDriver and test automation in general. I hope we will gain a lot of new Selenium/WebDriver enthusiastics. Probably I will also be involved in development of other technical courses.

Articles and conferences
Furthermore, I like to attend some conferences (like: Testnet.org, EuroStar) and write some articles to well-known magazines/websites (like: TestingExperience and SoftwareTestingClub.com).

Personal changes
But the best thing for the coming year is that we are going to have our first child 🙂 That means that I will work half days for 4 weeks, so I can spend some quality time with my wife and the baby.

Share This:

EuroStar conferentie 2012

In this post I like to look back at EuroStar Conference 2012. I was lucky this year, because I won a free EuroStar ticket from Software Testing Club! I had to win a contest where we had to invite as many friends as possible. I was happily surprised that they contact ~ME~ in the end. In this post I will write down all those things I remembered the best.

Wednesday, 7th November

Performance Testing of a Road Tolling System by Siegfried Goeschl
I was impressed by how the South-African government wasted so much money. They implemented and tested one of the world largest road tolling system, but never used it (well they use it, but for free). In the end, Siegfried presented a very good case study on how to performance test such massive system.

Testing of Cloud Services; The Approach: From Risks to Test Measures by Kees Blokland and Jeroen Mengerink
Another buzzword this conference was: The Cloud. Polteq had the opportunity to introduce a list with new concerns and risks and show how to mitigate them with tests or test-related measures. In the presentation they shared examples of these concerns and risks. The result was a very interesting presentation with a lot of clear examples.

Why Every System Test Department Should Have a Test Developer (Or Two…) by Kristoffer Nordström
Kristoffer clarified the role description of a Test Developer. He described the skill-set needed to be a Test Developer. Basically you will need both testing and development skills. (It should be someone who can talk with developers and testers). With a Test Developer in your team you have someone who can: do development (for tools), implement test automation, compile open source tools, reproduce complicated bugs and perform non-functional testing. (Looks like my daily tasks :))

Thursday, 8th November

Selenium Over the Years by Simon Stewart
Simon was talking about the history of Selenium back in the days when Web 1.0 ruled the world. He also mentioned all the difficulties we(they) have with different browsers. I remember one of his statements very well:

If you are testing web applications you need to be able to code, if not become a specialist so you can add value in a different area.

I think he’s right, because how can you test something properly, if you have no idea of how it is made.

Testing is Evolving. But Where Is The Evidence? by Andy Glover
Andy works in a highly regulated environment, providing evidence for all the things that are tested is part of his job. Andy explained that recording videos of every test execution is a way of collecting evidence. The advantage is that all the actions performed are recorded. However the disadvantage might be that there is less focus on the side-effects.

Testing the API Behind a Mobile App by Marc van ‘t Veer
Polteq was privileged to supply two tracks at EuroStar Conference. Marc presented a practical case study and explained what the benefits are of having an API behind a mobile App. He also described the additional risks we have to deal with. He emphasized that much more technical skills are needed when you need to test an API.

Test Lab – Coin Game
This time Bart Knaack (Test Lab founder) presented the Coin Game (I think Michael Bolton couldn’t make it). He had two hands full of coins and evaluated each coin. Each coin passed or failed an “unknown criteria. It was up to the delegates to guess the ”unknown” criteria were. The goal of this game was to determine a pattern within a big group of ”data” by asking exploratory questions.

Exhibitors
Kalistick they have a tool which can perform run-time code analysis. This means that you can get code coverage insights while executing manual or automated tests.
Telerik they have an App which allows you to do free record-and-playback Web Application testing.

Share This: