Testing CRUD Operations with Setup and Teardown in Dart
Testing CRUD Operations with Setup and Teardown
Welcome to another step in our journey to mastering automated API testing with Dart. Today, we'll focus on testing CRUD operations — Create, Read, Update, and Delete — which form the backbone of RESTful API interactions. We'll see how setup and teardown functions can streamline our testing process and ensure reliable, isolated tests.
Leveraging Setup and Teardown for CRUD Testing
When testing CRUD operations, we need a consistent environment for each test. This is where setup and teardown functions shine. Let's structure our test file:
Dart
import 'dart:convert';import 'package:http/http.dart' as http;import 'package:test/test.dart';void main() { final String baseUrl = "http://localhost:8000"; late int todoId; setUp(() async { // Setup code: Create a todo item for testing final response = await http.post( Uri.parse('$baseUrl/todos'), headers: {"Content-Type": "application/json"}, body: jsonEncode({ "title": "Setup Todo", "description": "For testing CRUD operations", "done": false }), ); if (response.statusCode != 201) { throw Exception("Failed to create a todo for setup"); } // Store the ID of the created todo final createdTodo = jsonDecode(response.body); todoId = createdTodo['id']; }); tearDown(() async { // Teardown code: Clean up the created todo item await http.delete(Uri.parse('$baseUrl/todos/$todoId')); });
Our setUp function creates a fresh todo item before each test, while tearDown removes it afterward. This ensures each test operates on a clean slate.
Why We Skip the Explicit Create Test
You might notice we don't have a dedicated test for the Create operation. This is intentional and efficient:
We're already testing creation in our setUp function
If creation fails, the setUp function throws an exception
This would cause all tests to fail, clearly indicating a problem with the Create operation
This approach avoids redundancy while still ensuring the Create functionality is thoroughly verified. If the API's Create endpoint has issues, we'll know immediately because no tests will be able to run.
Testing Read Operation
Join the 1M+ learners on CodeSignal
Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal
Partial Update with PATCH
Complete Update with PUT
Testing Delete Operation
The Power of This Approach
This structured approach to testing CRUD operations offers several advantages:
Efficiency: We test creation implicitly in setup, avoiding redundant tests
Isolation: Each test runs independently with fresh data
Completeness: We cover all CRUD operations thoroughly
Reliability: Cleanup happens automatically, even after test failures
Clarity: Each test focuses on a single operation, making the test intent clear
By organizing our tests this way, we create a robust suite that thoroughly validates our API's functionality while remaining maintainable and efficient.
Summary
In this lesson, we've seen how to structure tests for CRUD operations using setup and teardown functions. We've learned why we don't need a separate test for creation, how to test read and update operations, and how the delete test interacts with our teardown function.
This approach ensures comprehensive testing of your API while maintaining test independence and reliability. In the upcoming practice exercises, you'll apply these concepts to reinforce your understanding and build confidence in your API testing skills.
This test verifies we can retrieve the todo item and that its properties match our expectations.
The PATCH method is designed for partial updates, allowing clients to modify specific fields without sending the entire resource.
In our test, we'll focus on updating just the done status of our todo item. We'll first prepare the update data, then send the PATCH request, and finally verify that only the specified field was changed while the rest remained intact.
Dart
test('Update a todo with PATCH', () async { // Arrange final updateData = {"done": true}; // Act final response = await http.patch( Uri.parse('$baseUrl/todos/$todoId'), headers: {"Content-Type": "application/json"}, body: jsonEncode(updateData), ); // Assert expect(response.statusCode, equals(200)); final updatedTodo = jsonDecode(response.body); expect(updatedTodo['done'], isTrue);});
This test focuses on updating just one field, which is the primary use case for PATCH.
Unlike PATCH, the PUT method is used for complete replacement of a resource. In our test, we'll replace all fields of the todo item with new values. We'll then verify that the entire resource has been updated to match our new data. This ensures that our API correctly implements the PUT semantics according to RESTful principles.
Dart
test('Update a todo with PUT', () async { // Arrange final putData = { "title": "Updated Title", "description": "Updated Description", "done": true }; // Act final response = await http.put( Uri.parse('$baseUrl/todos/$todoId'), headers: {"Content-Type": "application/json"}, body: jsonEncode(putData), ); // Assert expect(response.statusCode, equals(200)); final updatedTodo = jsonDecode(response.body); expect(updatedTodo['title'], equals(putData['title'])); expect(updatedTodo['description'], equals(putData['description'])); expect(updatedTodo['done'], isTrue);});
Here we replace the entire resource, verifying all fields are updated correctly.
Finally, let's test the Delete operation:
Dart
test('Delete a todo', () async { // Act final response = await http.delete(Uri.parse('$baseUrl/todos/$todoId')); // Assert expect(response.statusCode, equals(204)); final getDeletedResponse = await http.get(Uri.parse('$baseUrl/todos/$todoId')); expect(getDeletedResponse.statusCode, equals(404));});
This test verifies that:
The delete request returns a 204 status (success with no content)
The resource is no longer accessible (404 Not Found)
Interestingly, after this test completes, our tearDown function will still attempt to delete the same todo item. This redundancy is actually beneficial—it ensures cleanup happens even if a test fails before completing its own delete operation. The delete request in tearDown will simply return a 404 status code, which doesn't affect our test results.
