Test fixtures and lifecycle in Kotlin - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is a test fixture in Kotlin testing?

A test fixture is the fixed state of a set of objects used as a baseline for running tests. It includes setup data and environment needed before tests run.

beginner

Which Kotlin testing annotation is used to run code before each test method?

The @BeforeEach annotation runs the setup code before each test method to prepare the test environment.

beginner

What is the purpose of the @AfterEach annotation in Kotlin tests?

It runs cleanup code after each test method to reset or release resources used during the test.

intermediate

How does @BeforeAll differ from @BeforeEach in Kotlin testing?

@BeforeAll runs once before all tests in a class, while @BeforeEach runs before each individual test method.

intermediate

Why is it important to use test fixtures and lifecycle methods in automated tests?

They ensure tests run in a consistent environment, avoid side effects between tests, and help isolate failures for easier debugging.

Which annotation in Kotlin runs code before each test method?

A @AfterAll

B @AfterEach

C @BeforeAll

D @BeforeEach

@BeforeEach runs setup code before every test method to prepare the environment.

What does a test fixture typically include?

A Only test method names

B Test data and environment setup

C Test results

D Compiler settings

Test fixtures include the data and environment setup needed before running tests.

Which annotation is used to clean up after each test method?

A @AfterEach

B @BeforeEach

C @BeforeAll

D @AfterAll

@AfterEach runs cleanup code after each test method.

When is @BeforeAll executed in Kotlin tests?

A Once before all tests in a class

B After each test method

C Before each test method

D Once after all tests in a class

@BeforeAll runs once before all tests in the test class.

Why should tests use lifecycle methods like @BeforeEach and @AfterEach?

A To make tests run slower

B To generate test reports

C To ensure consistent test environment and avoid side effects

D To skip tests

Lifecycle methods help keep tests isolated and consistent by setting up and cleaning the environment.

Explain what a test fixture is and why it is important in Kotlin testing.

Think about what you need before running a test to make it reliable.

Describe the difference between @BeforeEach and @BeforeAll annotations in Kotlin testing lifecycle.

Consider how often the setup code runs in each case.

Practice

1. What is the main purpose of test fixtures in Kotlin testing?

easy

A. To prepare and clean the test environment before and after tests

B. To write the actual test cases

C. To generate random test data automatically

D. To compile the Kotlin code before running tests

Solution

1. Step 1: Understand what test fixtures do

   Test fixtures set up the environment needed for tests and clean it afterward to avoid side effects.

2. Step 2: Identify the correct purpose

   Among the options, only preparing and cleaning the test environment matches the role of test fixtures.

3. Final Answer:

   To prepare and clean the test environment before and after tests -> Option A

4. Quick Check:

   Test fixtures = prepare and clean environment [OK]

Hint: Remember: fixtures setup and cleanup tests [OK]

Common Mistakes:

• Confusing fixtures with test case logic
• Thinking fixtures generate test data
• Assuming fixtures compile code

2. Which annotation in Kotlin testing runs a method once before all tests in a class?

easy

A. @AfterEach

B. @BeforeAll

C. @BeforeEach

D. @AfterAll

Solution

1. Step 1: Recall lifecycle annotations

   @BeforeAll runs once before all tests; @BeforeEach runs before each test.

2. Step 2: Match annotation to description

   The annotation that runs once before all tests is @BeforeAll.

3. Final Answer:

   @BeforeAll -> Option B

4. Quick Check:

   @BeforeAll = run once before all tests [OK]

Hint: BeforeAll runs once before all tests [OK]

Common Mistakes:

• Mixing @BeforeEach with @BeforeAll
• Confusing @AfterAll with @BeforeAll
• Using @AfterEach instead of @BeforeAll

3. Given the following Kotlin test class, what will be the output order of the print statements?

class SampleTest {
    @BeforeAll
    fun setupAll() = println("SetupAll")

    @BeforeEach
    fun setup() = println("Setup")

    @Test
    fun test1() = println("Test1")

    @Test
    fun test2() = println("Test2")

    @AfterEach
    fun tearDown() = println("TearDown")

    @AfterAll
    fun tearDownAll() = println("TearDownAll")
}

medium

A. Setup
Test1
Setup
Test2
TearDown
TearDownAll
SetupAll

B. Setup
Test1
TearDown
Setup
Test2
TearDown
SetupAll
TearDownAll

C. SetupAll
Setup
Test1
Test2
TearDown
TearDownAll

D. SetupAll
Setup
Test1
TearDown
Setup
Test2
TearDown
TearDownAll

Solution

1. Step 1: Understand lifecycle order

   @BeforeAll runs once before all tests, then for each test @BeforeEach, test, @AfterEach run, and finally @AfterAll runs once after all tests.

2. Step 2: Trace the print statements

   Output order: SetupAll (once), then for test1: Setup, Test1, TearDown; for test2: Setup, Test2, TearDown; finally TearDownAll.

3. Final Answer:

   SetupAll Setup Test1 TearDown Setup Test2 TearDown TearDownAll -> Option D

4. Quick Check:

   Lifecycle order = D [OK]

Hint: BeforeAll once, BeforeEach per test, AfterEach per test, AfterAll once [OK]

Common Mistakes:

• Assuming @BeforeEach runs once only
• Mixing order of AfterEach and AfterAll
• Forgetting @BeforeAll and @AfterAll run once

4. Identify the error in this Kotlin test fixture code snippet:

@BeforeAll
fun setup() {
    println("Setup")
}

@Test
fun testExample() {
    println("Test")
}

medium

A. @BeforeAll method must be static or inside a companion object

B. setup() should return a value

C. Missing @Test annotation on setup()

D. testExample() must be private

Solution

1. Step 1: Recall @BeforeAll requirements in Kotlin

   @BeforeAll methods must be static or placed inside a companion object to run once before all tests.

2. Step 2: Check the code snippet

   The setup() method is annotated with @BeforeAll but is not static nor inside a companion object, causing an error.

3. Final Answer:

   @BeforeAll method must be static or inside a companion object -> Option A

4. Quick Check:

   @BeforeAll requires static or companion object [OK]

Hint: @BeforeAll needs static or companion object [OK]

Common Mistakes:

• Thinking @BeforeAll can be a normal instance method
• Assuming test methods must be private
• Believing setup() needs a return value

5. You want to ensure a database connection is opened once before all tests and closed once after all tests in a Kotlin test class. Which is the best way to implement this using test fixtures?

hard

A. Use @BeforeEach to open and @AfterEach to close the connection

B. Open the connection in the constructor and close it in a test method

C. Use @BeforeAll inside a companion object to open and @AfterAll inside the companion object to close

D. Use @BeforeAll and @AfterAll as instance methods without companion object

Solution

1. Step 1: Understand lifecycle for shared resources

   Resources like database connections should open once before all tests and close once after all tests to save time and avoid repeated setup.

2. Step 2: Apply Kotlin @BeforeAll/@AfterAll rules

   In Kotlin, @BeforeAll and @AfterAll must be inside a companion object or be static to run once per class.

3. Step 3: Evaluate options

   Use @BeforeAll inside a companion object to open and @AfterAll inside the companion object to close correctly uses @BeforeAll and @AfterAll inside a companion object for one-time setup and teardown.

4. Final Answer:

   Use @BeforeAll inside a companion object to open and @AfterAll inside the companion object to close -> Option C

5. Quick Check:

   Shared setup/teardown = @BeforeAll/@AfterAll in companion object [OK]

Hint: Use companion object for @BeforeAll/@AfterAll in Kotlin [OK]

Common Mistakes:

• Using @BeforeEach/@AfterEach for expensive shared setup
• Placing @BeforeAll/@AfterAll outside companion object
• Opening connection in constructor instead of fixture