How I Implemented Test-Driven Development on My Team’s Project
So a long story short, I was taking one of the courses at my university, especially majoring in computer science, namely software projects (Proyek Perangkat Lunak). As the name implies, in this course I was given the task of creating a team of five people and making software with predetermined topics. My team got the topic of creating mobile applications that are involved in academia, especially in the field of law. The name of the application is Pantau Peradilanmu. Well, in this article I will briefly explain how I implemented TDD on My Team’s Project and the use of TDD itself.
What is Test-Driven Development?
TDD is the process of creating software by writing tests in advance to prove the implementation fulfills the requirements.
Rules of Test-Driven Development
Uncle Bob describes TDD with three rules:
- You are not allowed to write any production code unless it is to make a failing unit test pass.
- You are not allowed to write any more of a unit test than is sufficient to fail, and compilation failures are failures.
- You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
Those rules define the mechanics of TDD, but they are definitely not everything you need to know. In fact, the process of using TDD is often described as a Red/Green/Refactor cycle. Let’s see what it is about.
Red Green Refactor Cycle
Red Phase
In the red phase, you act like you’re a demanding user who wants to use the code that’s about to be written in the simplest possible way. You have to write a test that uses a piece of code as if it were already implemented. Forget about the implementation! If in this phase, you are thinking about how you are going to write the production code, you are doing it wrong!
It is in this phase where you concentrate on writing a clean interface for future users. This is the phase where you design how your code will be used by clients.
This first rule is the most important one and it is the rule that makes TDD different from regular testing. You write a test so that you can then write production code. You don’t write a test to test your code.
Green Phase
In this phase, you need to act like a programmer who has one simple task: write a straightforward solution that makes the test pass (and makes the alarming red on the test report become a friendly green). In this phase, you are allowed to violate best practices and even duplicate code. Code duplication will be removed in the refactor phase.
But why do we have this rule? Why can’t I write all the code that is already in my mind? For two reasons:
- A simple task is less prone to errors, and you want to minimize bugs.
- You definitely don’t want to mix up code that is under testing with code that is not. You can write code that is not under testing (aka legacy), but the worst thing you can do is mixing up tested and untested code.
Refactor Phase
The refactor phase is used to clean up the code. You are allowed to change the code while keeping all tests green so that it becomes better. What “better” means is up to you. But there is something mandatory: you have to remove code duplication. Kent Becks suggests in his book that removing code duplication is all you need to do.
TDD on My Team’s Project
In my team project, we use the flutter framework as the main basis for developing android applications. Flutter itself has three test categories, namely:
- A widget test (tests a single widget)
- A unit test (tests a single function, method, or class)
- An integration test (tests a complete app or a large part of an app)
In this article, I will give an example of how I implement the red-green-refactor cycle by testing one of the widgets that I will create. One of the widgets that I will create is the floating action button menu, where when I press the floating action button it will display a menu (custom modal) in the form of a dialog.
In accordance with the red-green-refactor cycle, the first step I did was to create a unit test. Here I created a unit test, which checks if a floating action button is pressed it will display a custom modal. Here is the test I made:
testWidgets("FAB test", (WidgetTester tester) async {await tester.pumpWidget(TestApp(authentication:MockAuthentication()));
expect(find.byType(CustomFAB), findsWidgets);
await tester.tap(find.byType(CustomFAB));
await tester.pumpAndSettle();
expect(find.byType(CustomModal), findsOneWidget);}
Then I implemented the code according to the unit tests that I made in the green phase.
class CustomFAB extends StatelessWidget {
const CustomFAB({Key? key}) : super(key: key);
@override
Widget build(BuildContext context) {
return FloatingActionButton(
onPressed: () {
showDialog(
context: context,
builder: (BuildContext context) {
return CustomModal(children: [])})};
In the last step which is refactoring, I just deleted some unnecessary comments.
So that’s how implemented TDD on My Team’s Project.
That’s all I can share regarding how I implemented TDD on My Team’s Project. Thank you for reading this article. I hope you like it.
