Skip to content
This repository has been archived by the owner on Jun 1, 2024. It is now read-only.

Android Tests Style Guide

igorgiumellizup edited this page Jan 5, 2021 · 5 revisions

Given-When-Then is a style of representing tests - or as its advocates would say - specifying a system's behavior using SpecificationByExample. It's an approach developed by Daniel Terhorst-North and Chris Matts as part of Behavior-Driven Development (BDD). It appears as a structuring approach for many testing frameworks such as Cucumber. You can also look at it as a reformulation of the Four-Phase Test pattern.

The essential idea is to break down writing a scenario (or test) into three sections:

The given part describes the state of the world before you begin the behavior you're specifying in this scenario. You can think of it as the pre-conditions to the test. The when section is that behavior that you're specifying. Finally the then section describes the changes you expect due to the specified behavior. Since we're talking about using examples as specifications, it makes sense to show this with an example:

Feature: User trades stocks
  Scenario: User requests a sell before close of trading
    Given I have 100 shares of MSFT stock
       And I have 150 shares of APPL stock
       And the time is before close of trading

    When I ask to sell 20 shares of MSFT stock
     
     Then I should have 80 shares of MSFT stock
      And I should have 150 shares of APPL stock
      And a sell order for 20 shares of MSFT stock should have been executed

The above example uses Cucumber, which is a popular way of writing business-facing test, but you can use the Given-When-Then notation with any kind of tests. Some people like to put Given-When-Then as comments to mark informal blocks inside unit tests. I've also seen this convention to structure informal prose.

It's usual with this approach to see "ands" used to combine multiple expressions within each clause.

I've characterized the given as a description of the pre-condition state because that's the way I prefer to think of it. A testing framework, however, interprets the givens as a set of commands to bring the system-under-test into the correct state before executing the when command. (Which is why other naming conventions often call this "setup".) Testing frameworks provide various query methods for the then commands - these should be free of side-effects.

Although Given-When-Then style is symptomatic to BDD, the basic idea is pretty common when writing tests or specification by example. Meszaros describes the pattern as Four-Phase Test. His four phases are Setup (Given), Exercise (When), Verify (Then) and Teardown. Bill Wake came up with the formulation as Arrange, Act, Assert.

Text from: https://martinfowler.com/bliki/GivenWhenThen.html

Example of the unit test:

@DisplayName("Given Insert Operation")
internal class InsertOperationTest {

    val insertOperation = InsertOperation()

    @DisplayName("When insert one item")
    @Nested
    inner class Insert {
        private val list = OperationType.TypeJsonArray(JSONArray(listOf(1, 2, 3)))
        private val item = OperationType.TypeNumber(9)

        @Test
        @DisplayName("Then should insert item in first position")
        fun insertItemFirstPosition() {
            // GIVEN
            val position = OperationType.TypeNumber(0)

            // WHEN
            val result = insertOperation.execute(list, item, position)

            // THEN
            val expected = OperationType.TypeJsonArray(JSONArray(listOf(9, 1, 2, 3)))
            assertEquals(expected.toString(), result.toString())
        }

        @Test
        @DisplayName("Then should insert item in the last position")
        fun insertItemInLastPosition() {
            // WHEN
            val result = insertOperation.execute(list, item)

            // THEN
            val expected = OperationType.TypeJsonArray(JSONArray(listOf(1, 2, 3, 9)))
            assertEquals(expected.toString(), result.toString())
        }
    }
}

Reference links to understand the pattern and how to write unit tests: