Just a TDD meme

In this article, I wanna talk about my experience with Test Driven Development (TDD) and its implementation on software engineering projects.

Disclaimer: since it’s based on my experience, this article can’t be really correct so take this article a bit of grain of salt.

What is Test-Driven Development?

  1. RED, in this phase, we create a test code for the implementation that will handle every possible scenario that could happen. We can also code the mock objects that are required for the testing in this phase.
  2. GREEN, in this phase, we create the implementation code that will pass the test created before.
  3. REFACTOR, after the implementation has passed the test, we can restructure the implementation to make it cleaner, more optimized, or more maintainable but still doesn’t break the correct logic.
https://content.codecademy.com/programs/tdd-js/articles/red-green-refactor-tdd.png

Rethinking About The Test Metric

TDD is Investment in Software Development

How I Use Test Driven Development in Software Engineering Project

RED

As you see, those two test cases use mocking on the SQL. I’ll talk about the mocking later on.

As you can see on the positive test (line 1–16), the test method starts with some dummy database setup since we can’t use the real database on testing. Once it’s all set, next thing is to insert a row on the dummy database using mock row . This will be useful for the mocking for the positive testing. The next thing is on line 9 is the mock part. Basically, the part is whenever there is a query like “SELECT FROM ‘users’” being called then it will return a database row which is a row that is previously inserted using mock row function. Since the inserted rows only have one row it’ll return one entity. Next is the method calling part (line 10–11). GetByID receives one integer called ID. This ID is used to search the user’s id in the database. In this part, I called the method with 1 as ID so it’ll search user that has 1 as ID because on mock row, I inserted a user that has 1 as ID. Finally, the validation part (line 12–16) will make sure that the user that is returned is the same as the user we really want to fetch (in this context, the intended user is a user that has 1 as ID) and no error returned.

The negative test is pretty much the same except there is no mockRows calling since I wanted to simulate an empty database and query mocking part (line 22). Instead of return a proper entity, it’ll return an error to signify that the specified user is not found in the database. The validation part(line 25–26) will make sure that an error is returned and the specified user isn’t fetched because when there is an error occurred, the method should return an error and the specified shouldn’t be fetched.

Tl;dr I created a positive test for the scenario when the thing goes as it’s intended to be (the specified user is found in the database) and a negative test to test the method behaviour whenever an error is occurred(ex: the specified user is not found in the database). I think that two kind of scenarios has already covered all possible scenarios that could happen on the method calling so these two tests are enough for me.

GREEN

GetByID implementation

In that phase, I created an implementation for the method. The method basically fetches user that has matching user id. That method returns the corresponding entity and zero error (or null) if the specified user is found on the database and return null & error if an error occurred instead.

REFACTOR

this really sparks joy

In refactor phase, I added the comment on the implementation since the linter requires to put a comment on every method on implementation except the private method. Here the GetByID is a public method (in go, a public method is signified by uppercase on the first letter while a private method is signified by lowercase on the first letter). I don’t put much comment on it since the method is already self-explanatory. The change is on the comment so it absolutely doesn’t affect the logic of the implementation.

It’s important to do refactoring as soon as possible unless your code is already clean

Final Words

That’s all folks about TDD from me. See you in the next post & have a good day!

References

https://martinfowler.com/bliki/AssertionFreeTesting.html