Red Green /Blue/Refactor/s

Published in

UKM Heroes

4 min readNov 7, 2019

UKM Indonesia is a website built for people to get information about starting a their business. This project is mostly front-end heavy where big chunks of the work is on the HTML and CSS files, but that doesn’t mean this project doesn’t need any sort of testing. In this project, we implement the Test Driven Development to ensure we know that our project works correctly before even deploy to production.

So what is it?

Test driven development is a software development process where developer works on small chunks of works with higher amount of confidence in each iteration. People also calls TDD a RED-GREEN-REFACTOR process. TDD allows developer to finish their work quicker overall development cycle.

Reason

It was quite hard for me to understand the importance of TDD when the first time we got introduced to it. I did not understand why would you create a test for a non existent code. Overtime, slowly I got the hang on why you should in most cases, do TDD. Here are the few take away from me learning TDD.

Less bugs

Bugs are unavoidable during a development process. Eventually, a bug or two will get introduce here and there. Without proper testing, these bugs can get carried out to a larger scale where some fix will require a huge changes where if the bugs detected early on, it can be fixed more easily.

Develop with confidence

Creating or modifying part of a code can cause side effects. Sometimes, these side effects can reach part of the features that are not currently developed. Since said features are not in current focus, these side effect can get past developer and carried into production. With good implementation of TDD, these side effects can easily detected which then the developer can adjust the new code or modify the other part of the code properly.

Maintainability

One of TDD practice is called Unit Testing (which I’ll elaborate later) encourage a development of a smaller component with low coupling and high cohesion. Unit testing will test small part of the code isolated (if possible) from the other part. This ensure high maintainability since it allow easy change to part of the code.

Cycle

As I’ve mentioned before, TDD also referred to as the RED-GREEN-REFACTOR process because of how the cycle works. In general, TDD has 3 cycle, red, green, and refactor. Red cycle is the cycle where we create a failing test deliberately. Developers are supposed to create a test for the features that they will be working. After developing the actual features, all those tests that has been created should pass, hence the green cycle. Usually the effort of creating the features while also passing the test resulted in a janky but working code. This will require a refactoring to the code more readable cleaner.

Testing

We use Angular as our front-end framework, it has two native testing framework. Karma for unit testing and Protractor for end-to-end testing.

Unit testing

The idea of unit testing that is to break down the test into small part. The purpose of doing this is so that the test itself is easy to create, clear what is the purpose, and low coupling. The general way to do unit testing is to test a small part of the code by giving it an input, then check whether the output is correct or not.

Consider these two code snippet. The StorageService have a method called uploadImagewhich will upload an image to an S3 server. A good practice to test a method is to create what is called a positive negative test.

A positive test is a test where the method is given a correct input, then we test the output of it. The spec should resolve if supplied with image is an example of positive test where the method uploadImage is given an image to upload. The method is supposed to return a resolved promise which is expected.

The other two specs is an example of a negative test. The method is given an incorrect input, one where the method is supplied with non image file and the other one is when the library rejected for some arbitrary reason. The method is expected to return a rejected promise.

End to end testing

The opposite of unit testing, instead of testing small individual part of the code, e2e test the entire application flow. The test is supposed to mimic real user interaction with the application. For example

sign up flow
upload file
testing redirect
etc

Coverage

One of the measurements on how good a tests for a project is to see the coverage. Most of testing framework has some sort of coverage reporting. For example, in this project we use Karma as the testing framework and Istanbul as the coverage reporting. Coverage is not an absolute measurements but it does help see the tests quality. One the practical use of having coverage is to fail a job if the coverage is below a certain threshold. Also git repository hosting like GitHub and GitLab has a feature where we can display the coverage in the readme or the repository description.

Passed

So far, we’ve only create a unit tests. We haven’t able to create an e2e tests since no features is fully completed yet. I’ve looking forward to learn more e2e and other kind of tests.

Thank you for reading!