Test Driven Development — Is it Really Necessary? How is it Implemented?
Test Driven Development, or in short, TDD, is a software development process, and as the name indicates, it relies heavily on the testing of the application. It has a fairly short development cycle, where the developers would write an initially failing test code. This test code would be the basic guideline to what the function will be. After the test code is created, the developers would try to make a function, a class, or a program that would satisfy the constraints of the test. After the program passes the test, it’s all a matter of refactoring to ensure the best code that could possibly be written.
The terminologies and descriptions can get confusing, so I’ll give some examples.
The first example I’m about to show you is the implementation of our app’s User and Psychologist class. These classes were made to save the data that the user have typed in the registration form, so passing data from one screen and another will be neater and easier. So before I made the user class, i thought of what variables would the class have, and what methods would be within the class. Since the class will only consist of getter and setter, the test would look like this.
Since the rest have similar implementation, as well as Psychologists, I’ll skip showing the screenshots for the test and show the class itself instead. If you run these tests, it will definitely give you a failed notice. This is what they call red, since the failed notice is in the color of red. Before you make the function, you should commit these changes with the tag “[RED]” in your commit message.
Since the test was made, I’d need to make a class with the functions that fit the constraints of the test. Below is the implementation.
Now, if you run the test again, since I’ve made a class that satisfies the constraints of the test, if I run the test again, it will give me a pass notice, which is what is referred to as green, since the passed color notice is green. Commit your changes with the tag “[GREEN]” on it.
That’s the very basic example of TDD. Everything that’s done needs to be tested, so I’ll show another example. This time, I’ll be making an update method in our api to connect our program with our database. This is the test I made for the method.
If I run the test, it will also give me a failed notice. So this is the method I’ve made to fit the constraints of the test.
What happens if I’d like to improve a code?
This case might happen often. Sometimes you give a vague name to a function or variable, and you only realize it later on that it’s not the best name. Sometimes you implement a slow-working algorithm and would like to implement a faster one. This doesn’t change the workings of the function, so you don’t need to retest it. This is called the refactoring step. You don’t need to make a new test for it. Simply make the changes and you’re done. When you’re about to commit your changes, include the tag “[REFACTOR]” in your commit message.
As an example, at first I made the Psychologist and User class separately without inheritance. So each classes would end up having similar attributes, like this.
I realize that this is not the most effective implementation. Psychologist has the same attributes as User, and Psychologist is a part of User. So instead of repeating myself over and over again, I decided to use inheritance. The User class remains the same, but the Psychologist class changes to this.
As you can see, it doesn’t change how the class Psychologist itself works. It’s still the same thing, just simpler. This is what can be considered refactoring, among many other examples. I simply have to commit my work under the refactor tag after this.
This all seems like a hassle at first. Making tests and such means that, technically, we’ll have more jobs to do, when sometimes all we want is to start coding and get it done with. But the existence of TDD makes the life of programmers easier, in a way, especially during the coding the actual program part. With the tests made, although it might consume some time at first, you’d already have a basic guideline to follow. You have what you need to make written out in the test, and before making the test you’d already think of a game plan for it. Meanwhile, coding without tests would usually mean that there are a heap ton of errors later on during the actual programming, or that the programmer themselves would be confused as to what step should they take next.
So is TDD really necessary? It’s not a must to implement this in your software developing, no, but along the way it’ll make your job a lot easier rather than going in blindly.
