Do We Need To Test This App?
TL;DR; Yes
Benefit:
- You could extend the app.
- You could refactor the app.
- You could experiment.
- Confidence doing that things above because you have the tests covers you. Something breaks, there’s high chance the test cases will tell you before the app going into production.
But I could do that too even if I do not test my application. Why bother testing?
Okay, let’s talk about some painful memories.
Faster Development
When we develop some feature, usually there are many type of input it could have, either desired on undesired input. From the specification, the developer would design the developed feature to be able to handle all case that they could imagine. They would build the function to comply with functions that they have in their head. When this input is given, this should be the response, When that input is given, the output should be like this.
We could just test it from browser or postman right, it’s quick and straightforward, isn’t writing test would slow down development time?
Yes, if you would test it only once, which you would not. You would create the basic feature, test it, update the code, test it, update again, and test it. Again, again, and again until you think you made it correctly according to the spec. Try to count it, how many times did you test your last feature assignment? I couldn’t count it, you couldn’t and wouldn’t too, there’s no point in doing that. It gave us the second important reason we write our test, we forgot.
From this two points which is repetition and human forgetfulness, it gave a sound reasoning for you to start writing your test case. You would not need to test the case one by one, the computer would do it for you and you just need to create instruction for it what to do. You would know what test should you run on this feature, because by creating the test, you would make a list about the behavior of your feature. There you go, you have made a list of the feature, now you could check the correct behavior and add or remove the test if it is not the behavior that the feature should be. Easier development time, no need for you to be paranoid, have I test that case? or keeping you wake up at night because there’s something that you forgot.
Extendability That Affect Architecture/Design Decision
This is a very important reason for you to start testing. When you already have an app that goes into production, it’s rarely the higher ups (or managers) would want to disrupt the app, they afraid it would affect the business. Because there’s no test that you could rely on to test the app before it is launched, the decision might became creating a new app to wrap around the current app, be it intercepting the request or intercepting the response. This is adding more things to maintain, (code, server, app, config, etc.). If you could extends the app, you only add/reduce small amount of code to the app that maintained already.
Design Patterns
By doing testing, you would think more about how would you design your code so you could test it reliably. It would inspire you to create a clean code too. If you make a function that has too much test, you would start questioning those function’s existence, does it do one thing and one thing only? this function needs this dependency to make it work, how would I make this work? how could this function do what it needs to do in test or in real case? is it the right way to do this?. These question would introduce you to clean code and design patterns. I started to understand how design patterns is used for and how I implement it, at the very least I could make a code that could run on both test and production environment, or in more general scale, how could I make more modular code that I could swap the implementation for a functionality in graceful way. Before doing testing, I read about design patterns but when trying to implement it I feel there’s some kind of invisible barrier that stops me.
CI/CD
CI/CD in short is the act of using automation to build, test, and deploy code into production, so the developer do not need to test and deploy manually each time a feature is added/removed, those act will be a git hook away. The interesting thing here is you could extend this automation, by testing your code using more than one machine or called parallel testing. Instead of using one machine to do the test, you divide the test across multiple machine. It would make the test goes faster than using a human tester.
Conclusion
This is my experience on starting doing testing. The first motivation for me to try testing is I wanted to be a better engineer, I want to level up, like those people who could create framework or package that is used by many people. And of all those things that I have learned about creating things, automated testing is an important part of development that let people build things together. Now that I have take the first step to learn testing, it enlightens me on on those benefits that I have mentioned above, tremendously. If you have not try writing some test, I encourage you to try it, and I hope that those step that you take will help you greatly too.
Have a great day.
