TDD: Saver or Blocker?
This article is part of Proyek Perangkat Lunak (PPL) or Software Engineering Project Course. Any information written here may or may not be true. Please use it wisely and let me know if there is any wrong information in it.
In this PPL course, we are required to do TDD on our code. But is TDD really necessary?
Wait, what?? You don't know about TDD? Okay, let’s get into it first
What is TDD?
Test Driven Development (TDD) is software development approach in which test cases are developed to specify and validate what the code will do. In simple terms, test cases for each functionality are created and tested first and if the test fails then the new code is written in order to pass the test and making code simple and bug-free.
The TDD cycle
When you are doing TDD you are locked in this cycle. These are the common steps in the TDD process:
- RED
So first we write just enough test code to make it fail. In this step, you try to run the test case. As there is no code, you will get compile error itself. This is referred as Red stage indicating failure of test case - GREEN
Then you start writing just enough production code to make that test work. - REFACTOR
In this step developer refactor the code to ensure the functionality is intact and code is refined, clean, and effective. There are some tools that can help you to refactor the code, one of them is sonarqube.
Why TDD?
Some of the benefits of TDD from what I understand and read:
- Tests ensure that the code stays focused and clear during each stage of development, that's reduce the possibility of bugs.
- No fear to change code. We all have had that big pile of bad code that no one dares to touch. Sometimes when we touch the code somehow the code is not working again. With TDD they make sure the code must run as it should.
- TDD makes the code simpler and clear. It allows the developer to maintain less documentation.
- etc
So far TDD sounds really good, right? Yeah, it is true. Hmmm, isn’t it(?).
Before further explanation let’s see how it is implemented in my PPL’s project.
Implementation in Sirclo Learning Lab
One of the features that use the TDD implementation in my project is the Module feature. Actually, it’s just CRUD feature, but can have so many negative test cases, because it’s TDD let’s make the test first
[!!!ATTENTION!!!]
The test code will be very, very, very, incredibly long, you can just scroll to the next section
How? Are you annoyed to see that long code? If yes, then calm down, because I feel it too 🙃. Okay, after struggling with the test let's commit it to GitLab.
Okay, RED as expected now let’s move to code implementation.
The code is not as long as the test, but you can scroll down too if you want.
Okay, let’s commit it to GitLab.
Nice GREEN as expected.
The Downside
Okay, do you feel annoyed with the TDD above? If yes, then let’s talk about the downside of TDD. The downside and also to reason why some people or companies don’t start with TDD is because the process adds 10 to 30% to the initial development costs. This is just reality, this is a development process that require time to get used to. Imagine you need to write 1200 line of test, only to test you 250 line of actual code. Of course it’s a waste of time isn’t it?
Why (people think) TDD is Bad?
- “We have a QA department, writing tests is their job”
Some companies don’t implement TDD because they feel it’s not their job but QA job. Leaving the test writing to the QA Department doesn’t, in my opinion, belong to a developer’s list of responsibilities. The QA’s have other more important things to do than spend their days primarily doing blackbox testing. - “Setting up the test, potentially with mocks and stubs, can be a lot of extra effort”
I understand the frustration. You need to implement a method which takes 3 different inputs, each of them being an object, each of them having no nullable attributes, and you want to test this and that and so on and so forth. To do so, you’ve got to set up Stubs and Mocks and that can be a lot of extra code for testing one method. - “It’s slow”
The developers who say this are usually the ones who have tried TDD out for a little while and then they went back to writing tests post-development. Regardless, this is the reason most often given as to why a developer does not do TDD. I can understand why people think that too. Thinking about code before it’s written, and spending extra time writing tests for everything that is implemented, even for the methods which may even have not had tests anyways, can take extra time. Including me, I feel TDD takes a lot of time.
But, Is TDD (really) stupid?
At first when I start using TDD I ask the same thing. Isn’t this going to slow me down? This kinda sounds like a waste of time to always write tests first. But after some time using TDD I think is necessary a good thing, it allows you to write a lot of quality code(fast != good). This TDD cycle keeps you awake and also make it easier to refocus efforts when you are disturbed. It makes you a better programmer more aware of creating clean code.
Okay before going to my final words, I want to share some difficulties when adopting TDD:
- The test is not run as expected, but the code does
With this problem, I think all I need to do is only to fix the test. I know maybe it’s wrong, but for beginners, I think nothing wrong with it. Adapting to TDD is not an easy thing for me, so I guess it’s a natural thing to do. - It’s hard to start with a test first
Same with the first problem, I think I used the illegal solution to fix it. Write the implementation first then write the test later, hehehe. Sorry for doing this 😔, but it’s really hard for beginners like me to implement the test first but as time goes by you will adapt to write the test first.
Final Word
Okay, so Is TDD Saver or Blocker? For me it’s both. If you use it for the first time, maybe it’s a blocker for you. It’s required a lot of time to write the test, then you also need to write the implementation. But as times goes by, it will be your saver, just like all tools and practices, Test Driven Development can be awkward at first and a little slow while you get the hang out it.
“If it hurts, do it more frequently, and bring the pain forward”
- Jez Humble
So instead you feel much pain at the end, it’s better to feel a bit of pain at the beginning 😊.
Thanks for reading and don’t forget to be grateful!
“You don't have to worry about failing tests, if you don't write any tests”
- Not me, of course
