Recap: in Part I, we looked at some “rules” we used to apply the “Arrange, Act, Assert” (AAA) pattern. In this part, we’ll look at some nuances, and how it sometimes highlighted issues in either the production or test code.

Phase labels

At the end of Part I, we were considering this larger test:

@Test
fun shouldReverseStringInput() {
// arrange
val exclaim = "!!"
val
firstInput = "cba"
val
secondInput = "gfed"
val
compoundInput = "$exclaim$secondInput$firstInput"

val
expectedReversedString = "abcdefg!!"

//act
val result = compoundInput.reversed()

//assert
assertThat(result).isEqualTo(expectedReversedString)
}

Although we can see where the three phases start and end, we should heed…


For the last 6 years I’ve been part of an Android team doing a lot of unit testing, usually with TDD. This is how we’ve been using the “Arrange, Act, Assert” (AAA) pattern as part of our daily routine, and what worked for us.

The AAA pattern for structuring unit tests has been around for a while now. This part (Part I) sets out what our team did in practice, to apply this pattern. Part II explores some nuances, including how at times it highlighted issues in our code.

Why do it at all?

Jeff Griggs enumerates the benefits of AAA in this succinct wiki…

Nelson Wright

I’m a Developer, working in Mobile for the last seven years or so.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store