My idea on Test-driven development was completely changed
we all at some point experienced the pain in writing, especially those who are not a fan of writing test cases, always trying to escape writing one, even if I was pushed to write the test cases, I would write it with haze. And most of the time I used to write it for getting the coverage.
Importance of writing test cases
of course, I have listened to many tutors saying the importance of test cases, why one should write test cases, why it is needed, etc did not actually get into my mind, I thought it is just a waste of time, I mean literally, mocking everything and testing just the code doesn’t add any value I thought, yes it also looks like that right? okay at least for me it looked that way.
Capturing the corner cases
come on guys focus more on corner cases, identify the corner cases where the code could break, and handle those scenarios. wrap everything inside one global try-catch, so that if any error comes the catcher catches it and it works. this is how I believed in writing the code. yes, nothing wrong with this but I will exactly tell you where this goes wrong.
Avoiding long debugging
whenever something goes wrong, especially in a big repo that has tones of code, then it becomes tricky, especially if it comes as a production issue, I personally experienced that in my life, I was literally on screen searching for a root cause and later found it is nothing to do from my end and it was some kind of data issue. Imagine knowing this after hours of debugging.
Taking the blame even though it is not your fault
This is the most embarrassing phase, you can literally sit for hours, code 1billion lines of code overnight, but taking the blame on your shoulders even though you are not completely sure that it was something from your code is the worst part.
Feeling insecure about your own code
yes, when you write more lines of code or which have more logic in it or even include or get data from others code is where your insecurity is. you will never know why the code breaks or why it is throwing an error. interestingly if you belong to this section of people. soon, you will need to evade yourself from writing the code. so with more code, more insecurity kicks in.
In case of controversies, you almost need an advocate to speak on your behalf.
yes, I mean who wants the blame if something is not wrong from their end? or at least in times where something is not even proven? you have to stand for your self and this is where communication pitches in, if your communication is also not that great, then you have knocked out bro. I am sure the other one wins if he is great in communication.
so, all for all these problems, one solution
Test-driven development
so in case, you are in any of these problems, or even close to it. if you don’t want to involve in any unnecessary troubles, and most importantly, your code should speak on behalf of you, then you must excel in writing the test cases. most importantly the test-driven approach. Trust me it does wonders. enough of saying, let us understand all these with a simple example.
addTwo(x) {
const y = getValueOfY(x); // async call
return x + y;
}I hope you get the above code, you pass the value of x, so you get the value of y by passing x to the call adding the sum, and returning it.
so if you push the above code, the chances of you ticking all the problems which I highlighted is almost 100%. Maybe if you are a little smart and you update the code as below
addTwo(x: number) {
try {
const y = getValueOfY(x); // async call
return x + y;
} catch () {
// do something
}this solves the majority of the problems yet it is not 100%. for this if your write test cases after you write the code, with one positive scenario and the negative scenario, done, you got your 100% code coverage.
wait!
this is actually where you invite the bigger problems and this is what I wanted to educate you all who are just like me, at my level in writing code.
if you want to write a perfect code, follow the steps
first to make your testbed. and create a bed for testing the add method. so even before you start your actual code you have your testbed ready, which is ready for TTD.
here is the approach
firstly, I imagine, the code gets input as a parameter and it should be a valid one, and I should get the value in return so that I can add it and return the response. so I just write the test cases saying the same
testcases
here is the list of testcases i can write for this
1) firstly the file should contain "addTwo" method
2) for that method there is an parameter, if it is not passed it should throw an err
3) i know i am getting a value from some other method, so that method also should be there and return a valid resposne, if not it should throw an err
4)incase if the inner method throws an error, my method should catch it and wrap it
5) if everything is good it should return me the value
6) even if something fails in any other scenario, it should throw an error from my method.
7) so irrespective of the, err, it should log it. with appropraite msg in each scenario///////////////// actual code////////////addTwo(x: number) {
try {
if (x) {
const y = getValueOfY(x); // async call
if (y){
return x + y;
} else { throw error('x value id not valid')}
} else { throw error('x value id not valid')}
} catch (e) {
log(e); throw error('add cannot be performed')}
}
credits: I don’t want to own the credits, with the same example, one of my colleagues taught me this and I thought this needs to spread.
