Welcome to another step in our journey to mastering automated API testing with Scala. So far, you've learned how to organize tests using MUnit classes and fixtures. In the last unit, we saw how fixtures can be used to provide data to multiple tests, making our test code more reusable and maintainable. Now, 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 makes sure tests don't interfere with each other.

We'll use MUnit's FunFixture 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.

FunFixture handles 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 MUnit's FunFixture. This fixture automates the process, ensuring each test starts with the right conditions and ends without leaving any trace. By using FunFixture, the setup and teardown logic is encapsulated, so you don't need to invoke it 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 fixture is structured in Scala:

Scala
Copy to clipboard
1import munit.*
2import requests.*
3import ujson.*
4
5class CrudOperationsSuite extends FunSuite:
6
7  val BASE_URL = "http://localhost:8000"
8
9  val todoFixture = FunFixture[(Int, Value)](
10    setup = _ => 
11      val todoData = Obj(
12        "title" -> Str("Setup Todo"),
13        "description" -> Str("For testing CRUD operations"),
14        "done" -> Bool(false)
15      )
16      val createResponse = requests.post(s"$BASE_URL/todos", data = todoData)
17      assert(createResponse.statusCode == 201)
18      val todoId = ujson.read(createResponse.text())("id").num.toInt
19      (todoId, todoData)
20    ,
21    teardown = (todoId, _) => 
22      requests.delete(s"$BASE_URL/todos/$todoId", check = false)
23  )

Within this fixture, the setup actions occur before each test to create a todo item, ensuring the test environment has the necessary data. 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. Note that we use check = false in the teardown to prevent exceptions if the todo was already deleted during a test.

With setup and teardown processes in place using MUnit's FunFixture, we establish a consistent environment for our tests. Now, we'll define the specific tests for each CRUD operation within the CrudOperationsSuite class. These tests will leverage the setup todo item, ensuring that we assess the ability to create, read, update, and delete resources accurately. Let's explore each operation through dedicated test methods.

In our CRUD operations, the Read test checks if we can successfully retrieve a todo item. Using the requests.get method, we fetch the todo item created during the setup. The test verifies the HTTP status code is 200, indicating success, and it asserts that the data returned matches our expectations. This confirms that our API's read functionality works correctly.

Scala
Copy to clipboard
1todoFixture.test("should read todo")((todoId, todoData) =>
2  // Act
3  val response = requests.get(s"$BASE_URL/todos/$todoId")
4
5  // Assert
6  assertEquals(response.statusCode, 200)
7  val fetchedTodo = ujson.read(response.text())
8  assertEquals(fetchedTodo("title").str, todoData("title").str)
9  assertEquals(fetchedTodo("description").str, todoData("description").str)
10  assertEquals(fetchedTodo("done").bool, todoData("done").bool)
11)

The Update operation using PATCH focuses on modifying specific fields of a todo item. Here, we send a PATCH request to change the done status to True. The test checks if the status code is 200, confirming the update was successful. We also verify the field was accurately updated in the API. This ensures that partial updates with PATCH are functioning as intended.

Scala
Copy to clipboard
1todoFixture.test("should update todo with patch")((todoId, _) =>
2  // Arrange
3  val updateData = Obj("done" -> Bool(true))
4
5  // Act
6  val response = requests.patch(s"$BASE_URL/todos/$todoId", data = updateData)
7
8  // Assert
9  assertEquals(response.statusCode, 200)
10  val updatedTodo = ujson.read(response.text())
11  assert(updatedTodo("done").bool)
12)

For a complete replacement of fields, the Update operation using PUT is employed. This test sends a PUT request to replace all fields of the todo item with new data. We assert the status code is 200, indicating the operation succeeded, and confirm that all fields match the updated values. This test validates that full updates with PUT are correctly processed by the API.

Scala
Copy to clipboard
1todoFixture.test("should update todo with put")((todoId, _) =>
2  // Arrange
3  val putData = Obj(
4    "title" -> Str("Updated Title"),
5    "description" -> Str("Updated Description"),
6    "done" -> Bool(true)
7  )
8
9  // Act
10  val response = requests.put(s"$BASE_URL/todos/$todoId", data = putData)
11
12  // Assert
13  assertEquals(response.statusCode, 200)
14  val updatedTodo = ujson.read(response.text())
15  assertEquals(updatedTodo("title").str, putData("title").str)
16  assertEquals(updatedTodo("description").str, putData("description").str)
17  assertEquals(updatedTodo("done").bool, putData("done").bool)
18)

The Delete test checks if a todo item can be removed successfully. A DELETE request is sent to the API, and the test verifies the status code is 204, signifying a successful deletion with no content returned. To confirm the deletion, we attempt to retrieve the same todo item and expect a 404 status code, indicating it no longer exists. This ensures the API's delete functionality behaves as expected.

Scala
Copy to clipboard
1todoFixture.test("should delete todo")((todoId, _) =>
2  // Act
3  val response = requests.delete(s"$BASE_URL/todos/$todoId")
4
5  // Assert
6  assertEquals(response.statusCode, 204)
7  val getDeletedResponse = requests.get(s"$BASE_URL/todos/$todoId", check = false)
8  assertEquals(getDeletedResponse.statusCode, 404)
9)

In today's lesson, we've delved into the essentials of testing CRUD operations with setup and teardown using MUnit's FunFixture. You've seen how automating these processes helps maintain a structured and reliable testing environment. Now, it's your turn to practice these concepts with hands-on exercises that will reinforce your understanding and confidence in applying these techniques.

As you continue to build your skills, you'll be better equipped to ensure API robustness and reliability. Keep up the great work, and prepare to explore testing authenticated endpoints moving forward!