TDD(Test-Driven Development)
By: Akbar Novial
Tags: Tdd

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.

The tests for “Disabilitas Mental” page

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.

Source: Brett Schuchert, Tim Ottinger

Fast : Tests should be fast. Slow tests would make you truant in running them.

: 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.