Testing CRUD Operations in Kotlin with JUnit and OkHttp

Welcome to another step in our journey to mastering automated API testing with Kotlin. So far, you've learned how to organize tests using JUnit and OkHttp. Today, we will focus on automating tests for CRUD operations — Create, Read, Update, and Delete — which are integral actions for managing data in any application that uses RESTful APIs. Automated testing of these operations is essential to ensure that APIs function correctly and modify resources as expected. Thorough testing of CRUD operations will help you catch issues early and ensure API reliability.

In automated testing, setup and teardown are fundamental concepts that help ensure each test has a clean start and finish. Setup is about preparing what you need before a test runs, like creating test data or setting up configurations. Teardown involves cleaning up afterward, removing any leftovers from the test, such as deleting test data, so future tests aren't affected. This process ensures tests don't interfere with each other.

We'll use JUnit's @BeforeEach and @AfterEach annotations to make setup and teardown automatic. Imagine testing a todo API with CRUD operations:

• Setup Phase: Runs before every test to create a fresh todo item, providing each test with the necessary starting data.
• Teardown Phase: Runs after every test to delete the todo item, ensuring no leftover data impacts subsequent tests.

These annotations handle these phases automatically, before and after every test, keeping your tests independent and the environment clean.

To effectively manage setup and teardown for CRUD operations, we utilize JUnit's lifecycle annotations. These annotations automate the process, ensuring each test starts with the right conditions and ends without leaving any trace. By using @BeforeEach and @AfterEach, the setup and teardown run automatically before and after each test in the class, so you don't need to invoke them manually in every test. This means every test begins and ends with a clean state, which is crucial to avoid any interference between tests.

Here's an example of how the setup and teardown are structured:

import kotlinx.serialization.*
import kotlinx.serialization.json.*
import okhttp3.*
import org.junit.jupiter.api.*
import kotlinx.coroutines.runBlocking
import okhttp3.RequestBody.Companion.toRequestBody
import okhttp3.MediaType.Companion.toMediaType

@TestInstance(TestInstance.Lifecycle.PER_CLASS)
class TestCRUDOperations {

    private val client = OkHttpClient()
    private val baseUrl = "http://localhost:8000"
    private lateinit var todoId: String
    private val json = Json { ignoreUnknownKeys = true }

    @Serializable
    data class Todo(
        val id: String? = null,
        val title: String,
        val description: String,
        val done: Boolean
    )

    @BeforeEach
    fun setup() = runBlocking {
        val todoData = Todo(
            title = "Setup Todo",
            description = "For testing CRUD operations",
            done = false
        )
        val jsonBody = json.encodeToString(todoData)
        val requestBody = jsonBody.toRequestBody("application/json".toMediaType())
        val request = Request.Builder()
            .url("$baseUrl/todos")
            .post(requestBody)
            .build()

        client.newCall(request).execute().use { response ->
            if (!response.isSuccessful) {
                throw Exception("Failed to create a todo for setup")
            }
            val responseBody = response.body?.string()
            val responseData = json.decodeFromString<Todo>(responseBody!!)
            todoId = responseData.id!!
        }
    }

    @AfterEach
    fun teardown() = runBlocking {
        val request = Request.Builder()
            .url("$baseUrl/todos/$todoId")
            .delete()
            .build()

        client.newCall(request).execute()
    }
}

The @TestInstance(TestInstance.Lifecycle.PER_CLASS) annotation is used to specify the lifecycle of the test instance in JUnit. By default, JUnit creates a new instance of the test class for each test method, which can be resource-intensive if the setup is complex or if there are many tests. Using @TestInstance(TestInstance.Lifecycle.PER_CLASS) allows JUnit to create a single instance of the test class for all test methods, which can be more efficient. This is particularly useful when you have shared state or expensive setup operations that you want to perform only once per class. However, it also means that you need to be careful with shared state between tests, as they will all run on the same instance.

Within this setup, the actions occur before each test to create a todo item, ensuring the test environment has the necessary data. The @AfterEach annotation ensures that after each test, the teardown actions delete the created todo, maintaining a clean slate for subsequent tests. This ensures consistent, independent test runs free from interference caused by leftover data.