logo logo

The 3 “A”s For Building a Great Test Automation Suite

main post image

Writing high quality test automation suite is not easy, especially for manual testers who are relatively new to automation. There is a learning curve. But the cost of not writing high quality test code, both in terms of maintenance and time wasted on unreliable or hard-to-update tests, is unsustainable for any but the smallest project. This article looks at one simple technique that can help testers write better organised tests that are easier to understand and to maintain.

Arrange, Act, Assert – The 3 “A”s, are a common way of organizing unit tests, and they apply equally well to automated acceptance tests. Indeed, many real-world tests could be made more readable and easier to maintain simply by respecting these principles.

The Arrange-Act-Assert pattern breaks a test into three parts:

  • Arrange: prepare the context.
  • Act: perform the action we want to demonstrate.
  • Assert: show that the outcome we expected actually occurred.

In Behavior Driven Development (BDD), acceptance criteria is often organised in the same way, using the Given-When-Then format. The difference is one of the levels of abstraction: The Arrange-Act-Assert pattern describes what the test code is doing, whereas Given-When-Then reason in terms of what user action the test is describing. For this reason, I generally prefer to use the terms Given-When-Then for acceptance tests.

What does good look like? 

The following test illustrates the Arrange-Act-Assert (or Given-When-Then) structure:

@Test
public void should_be_able_to_check_in() {
    // ARRANGE / GIVEN
    PetHotel hotel = new PetHotel();
    Pet fido = Pet.dog().named("Fido");

    // ACT / WHEN
    hotel.checkIn(fido);

    // ASSERT / THEN
    assertThat(hotel.getRegisteredPets(), 
               hasItem(fido));
}

This test makes it very clear which action we are illustrating (checking in a pet to the pet hotel), and what outcome we expect (the Fido should be in the list of registered pets).

On the other hand, the following test is less clear:

@Test
public void checking_in_several_pets() {
    PetHotel hotel = new PetHotel();
    Pet fido = Pet.dog().named("Fido");
    Pet ginger = Pet.cat().named("Ginger"); 
    hotel.checkIn(fido);
    hotel.checkIn(ginger); 
    assertThat(hotel.getRegisteredPets(), 
               hasItems(fido,ginger));
    hotel.checkOut(ginger);
    Pet fluffy = Pet.rabbit().named("Fluffy");
    hotel.checkIn(fluffy);
    assertThat(hotel.getRegisteredPets(), 
               hasItems(fido,fluffy));
}

Things here are a lot more confused. We need to read it through carefully to understand what it is trying to test. There are several assertions at several points in the test, which makes it harder to see what the test is trying to demonstrate. And there are many reasons that this test might fail, which makes it harder to troubleshoot and debug.

Less is more

The test shown above would be easier to understand if we refactored it into two separate tests, following the Act-Arrange-Assert structure:

Pet fido = Pet.dog().named("Fido"); 
Pet ginger = Pet.cat().named("Ginger");
Pet fluffy = Pet.rabbit().named("Fluffy"); 

@Test
public void checking_in_several_pets() {
    // GIVEN 
    PetHotel hotel = new PetHotel();

    // WHEN
    hotel.checkIn(fido);
    hotel.checkIn(ginger); 

    // THEN
    assertThat(hotel.getRegisteredPets(), 
               hasItems(fido,ginger));
}

@Test
public void should_be_able_to_check_out() {
    // GIVEN
    PetHotel hotel = APetHotel.withGuests(fido, ginger, fluffy);

    // WHEN
    hotel.checkOut(ginger);

    // THEN
    assertThat(hotel.getRegisteredPets(), 
               hasItems(fido,fluffy));
}

Both of these tests are smaller and more focused, and only do one thing. As a result, they are easier to understand, and if they break you will have a better idea of why.

Conclusion

Arrange-Act-Assert is a good rule of thumb for both unit and acceptance tests. A few good things to keep in mind when using this pattern are:

  • Asserts are meant to demonstrate as much as they prove: like in mathematics, a proof is useless if the reader doesn’t understand it. Make sure your assertions make clear what you are trying to demonstrate.
  • One assert focuses, two asserts distract: the more assertion statements you have, the less clear it is what you are trying to check. If you have many related assertion statements, consider writing a custom matcher or method to group them together.
  • Arrange code can often be reused: if you are getting large blocks of code in your arrange sections, see if you can refactor it in a way so that you can reuse it for other tests.

What is your opinion on these 3 “A”s? Do you implement this technique in your test automation project?
Please let us know what you think in the comment section below!

John Ferguson Smart

Avatar

About the author

John Ferguson Smart

John is a speaker, author, mentor and internationally-recognised specialist in building high performing teams and organisations through collaborative practices such as BDD, Test Automation, Software Craftsmanship. John is also the founder of the Serenity Dojo online training programme (http://www.serenity-dojo.com) that helps give testers the technical skills they need to survive in a world dominated by automation. John helps organisations and teams around the world deliver software that makes a difference sooner, through more effective collaboration and communication techniques, and through better technical practices. John is the author of the best-selling book "BDD in Action", as well as "Jenkins: The Definitive Guide" and "Java Power Tools". Very active in the Agile, BDD and Open Source communities, John also leads development on the innovative Serenity BDD test automation library.

Join TestProject Community

Get full access to the world's first cloud-based, open source friendly testing community. Enjoy TestProject's end-to-end test automation Platform, Forum, Blog and Docs - All for FREE.

Join Us Now

Comments

13 1 comment
  • Avatar
    esantana November 19, 2018, 10:39 am

    Hi John,

    Great post. I’d like to know your thoughts about using the 3 A’s when using page objects. Because the same method that I’m finding the XPath in the page object, I already asserted in there as I’m going to use the same guy in 5 different tests and the same Assert. What do you think about using like that and what would be the advantages of changing for the 3 A’s?

    Thanks

Leave a Reply

Join TestProject Newsletter

Join a 20K community of readers! Always stay up-to-date with all the latest test automation trends, best practice and tips shared by leading software testing community experts across the globe!

FacebookLinkedInTwitterEmail