TDD(Test-Driven Development)

Published in

bisaGo2020

6 min readOct 21, 2020

All Code Is Guilty Until Proven Innocent!

taken from https://www.freecodecamp.org/news/test-driven-development-what-it-is-and-what-it-is-not-41fa6bca02a2/

Test-Driven Development, also known as TDD, is a method in software development where the developer specifies the test cases first and validates what the code will do. This method may be different from the common ways people do programming. Usually, when beginner developers already have software to develop in mind, they would specify the requirements and start working on the code immediately. This, however, could lead to problems in the future. When creating software, there are often cases where the requirements can change, which would lead to creating more features or modifying the existing code and would lead to the appearance of bugs. If we don't implement TDD, it would make the process of debugging much more of a hassle. That’s where TDD comes into play.

TDD requires the developers to create the test cases for each functionality beforehand. Although this may make the development process a little longer, it will be worth it. How can it be worth it? because by doing so, the developer knows that if the test fails, new code will be written in order to pass the test, making the code bug-free.

My team and I also use Test-Driven Development to work on our current project. Here, I’ll show you how to do it so we can also develop our skills as programmers.

How do we perform TDD?

taken from http://www.agiledata.org/essays/tdd.html

Create the tests before writing the actual code. This will ensure us to think of all of the possible outcomes or situations that could happen to our software.
Run the tests. Make sure to first initialize the tests to fail. You must be wondering, why on earth would I purposely fail the test? Well, you have to because you haven't actually written any of the code that would pass the test.
Start working on the actual code with the goal to pass the tests you’ve specified beforehand.
Run the tests and check if your code has passed the tests. If not, you need to repair the code.
REFACTOR. If you ever feel like the code you created is still messy, and could be further improved, don’t hesitate to do some refactoring. Refactoring could lead to clean code which would bring lots of benefits.
Repeat. That’s right, once you’ve done all of the steps, you need to iterate them until you finally reach your final product.

7 TDD habits that can make your life easier

Taken from my university’s slides, these are some routines during TDD that could very much help everyone.

1. Test First

As I mentioned before, start the development by creating the test cases. However, this time, apply the RED-GREEN-REFACTOR principle.

taken from https://www.kamui.co.uk/2018/07/01/test-driven-development-tdd-a-practical-example/

What I mean by Red, Green, and Refactor, these are the tags you use when you commit your work to your online repository. [RED] is when the test fails, [GREEN] is when your code has passed the tests, and [REFACTOR] is when you want to make some changes or enhance your code by taking into account that your code still passes the tests.

2. Acceptance Criteria

All tests created must refer to the Acceptance Criteria that must be written in detail in the user story. I’ll provide the Acceptance Criteria for my team’s project, BisaGo!

3. Online Repository

Nowadays, it is much easier to do code development because of the presence of online repositories, such as GitLab, GitHub, etc. These online repositories also can make you work with your team much easier, without fear of overwriting each other’s files. You can read more about Git, in the other article I’ve published, “Git” Good!. My team uses GitLab as our online repository.

4. Commit Milestone [RED]

Each step, development must begin with a test, with the commit message [RED]. Commit first, work on implementation later.

5. Clean Test

We can do this by implementing the F.I.R.S.T principles when creating the tests. When working on my project, I work on the front-end of it. So, the examples I show here are all shows the tests for the front-end which implement the principles.

Fast: Tests should be fast. Slow tests would make you truant in running them.
Independent: Tests should not depend on each other and should be able to run in any order. The tests in my project are also isolated from each other, as they could be run separately and do not depend on one another.

Repeatable: Tests should be repeatable in any environment. The tests I have created also are ensured to be able to run not just on my local computer, but also in any environment.

Self-Validating: Tests should have a boolean output. You should not have to read through a log file to tell whether the tests pass. We can see from the picture below that the tests for flutter use expect for assertions.

Timely: Tests need to be written in a timely fashion, which is before the actual production code. Because I implement TDD when working on my project, I always start with creating the tests first and pushing them to my repository using the “[RED]” tag.

6. Commit Milestone [GREEN]

Once you’ve completed a task in the repository and you’ve made sure that it has passed the test, you must push your code with the [GREEN] tag in your commit. It would then be confirmed by executing the test on the CI/CD pipeline.

7. Code Coverage

Code Coverage is one of the quantitative measurements that determine the quality of the code. It does so by measuring the comprehensiveness of the code. When working on software, we should enforce achieving the code coverage of 100%. If not, it means that the unit tests made are still lacking and haven’t covered all parts of the code.

The coverage for the Tentang Disabilitas PBI

That is all from me regarding Test-Driven Development and the importance of using this methodology. I hope this can be useful for our development as programmers.

Back-End & Front-End Tests

In my project, we use Django for our back-end and flutter for our front-end. So, this means that the testing we do would also be different. The differences between these tests are that:

Back-end tests are usually created to cover the APIs, such as if there is a certain input, it should give a certain response. Below is an example of a back-end test taken from the BisaGo repository.

an example of a back-end test for “Informasi Fasilitas” page

Front-end tests mostly cover whether a certain widget is present or not on that page. It also tests whether the components(buttons, etc) in the pages function correctly or not. Furthermore, the front-end tests can have both positive and negative tests. The positive tests are where we provide valid data sets as inputs, while the negative tests are where we provide improper data sets.