Test it before you make it

People sometimes question the importance of creating tests before making the software itself. Well, i did. But when I experience TDD itself, I’d never skip a test, since the requirements always change.

TDD (Test Driven Development) is an evolutionary approach to development which combines test-first development where you write a test before you write just enough production code to fulfill that test and refactoring.

One view is the goal of TDD is specification and not validation (Martin, Newkirk, and Kess 2003). In other words, it’s one way to think through your requirements or design before your write your functional code (implying that TDD is both an important agile requirements and agile design technique). Another view is that TDD is a programming technique. As Ron Jeffries likes to say, the goal of TDD is to write clean code that works.

A significant advantage of TDD is that it enables you to take small steps when writing software. This is a practice that I have promoted for years because it is far more productive than attempting to code in large steps. For example, assume you add some new functional code, compile, and test it. Chances are pretty good that your tests will be broken by defects that exist in the new code. It is much easier to find, and then fix, those defects if you’ve written two new lines of code than two thousand.

“The act of writing a unit test is more an act of design than of verification. It is also more an act of documentation than of verification. The act of writing a unit test closes a remarkable number of feedback loops, the least of which is the one pertaining to verification of function” — Bob Martin

So in short, the benefits of TDD are:

• Modular programming code
• Easy refactoring and code maintenance
• Fruitful team collaboration
• Bugs prevention
• Requirements clarification

Here are some steps to perform TDD test:

• Write a test
• Confirm the test fails
• Write code to pass the test
• Confirm the test passes
• Refactor
• Repeat all steps

It’s basically as simple as UI Test and Unit Test. What is the difference between both?

A unit test only tests one single class per test. Any objects that the class would need to interact with should be replaced with a fake object that the test controls. If you don’t insert fake objects you have no way of knowing if a failed test is from the thing you were really trying test or something that it uses.

Meanwhile..

UI Tests make use of the accessibility features of Apple’s various platforms to effectively pretend to be a user using the app. So we have to make sure to test every UI elements we’re going to add in the future.

For example we’re going to build this login page. Before we make the page, we create the test first.

We can see here that there are 3 UI elements that need to be tested. They are email and password text field and ‘Masuk’ button. Therefore, we can test those three with this function:

You can see that the code tests all the UI elements. It acts like the real user, since it really taps on the text field and types an email and a password and taps on the ‘Masuk’ button. If you run the UI test, it’ll look like this.

As for the Unit Test, we have to test two conditions, where the user inputs the right login account and the wrong one.

Let’s use the same example above so we can get the big picture. When I finish creating the UI Tests, I push them to GitLab with commit message “[RED] UI Test Login Page”, as well for the Unit Test.

[RED] means that the test is failed so it makes the pipeline is failed. I haven’t written the code to pass the test, so the test doesn’t find any elements that it is testing.

So I write the code and push it with the commit message “[GREEN] create login page” (sorry if I wrote it in Bahasa).

And as like what you’re guessing, [GREEN] means that the test is succeeded since the implementation code has been made.

Although, there are times when we have to refactor the code all over again in order to make the test succeed.

[REFACTOR] means that I change and change the implementation code until the test is succeeded. It needs an effort, but it will be worth it ;)