Why should I write tests?

Why? Why..? Why....??

This is an easy one. Because we do not want to ship our code to production without testing it.

But why? Really?

Why really? I mean, I could just run my code and test(it is a faster way to do it for me). I could just ctrl+f5 the page and test my code. Why should I put in the efforts and time to write those tests? (Change-My-Mind.png)

Yes, It is really important to know why should I write the tests before I start writing important tests. Otherwise, it'd feel more of a burden than the right cause.

It's all cool if it is some static content change and you and your peers have verified it. You could just compare the text given for task with the updated on the page. Tests can't catch grammar mistakes. 🙂

Let's say for an example:

"Jessie"(who is part of the team Rocket ) added username, password, and age fields for the sign-up form. "Jessie" went to the page and tested that the fields are visible, accepting the data, validating the username(uniqueness and some char length - the strictness in the column with varchar length as well, etc), some validation for the password(8 min chars, numbers, special char etc), and age fields(say minimum 13 years old). "Jessie" deployed the code and lived happily ever after started working on other tasks.

>> Fast-Forward 2 months...

"James" from team Stars(newly forked from team Rocket) decided it is high time we start collecting emails of our users since we're seeing a lot of signups. We're ready to bother our users with our evil product plans. We just need their emails now to get into the endgame.

So, "James" takes up the task, adds a new field on sign-up page(called email off-course), looks at the username's uniqueness validation code, insert their email field there and finds out the page is not accepting the length more than 6 chars. Uh, oh, the length needs to be increased because email could be "spammyuserwithexample@randompokemon.com", changes the minimum length to 15, tests the page the same way "Jessie" did because "James" admires "Jessie" and follows their footsteps.

Everything is good because UI validation takes care of limiting username to 6 chars and "James" was more focused on testing the email stuff and did not try a case where username has more than 6 chars because UI took care of it. The code is deployed.

The next day "Jessie"  and "James" are staring at 100+ exception emails stating DB could not save username field as the length size exceeds the limit. Because of a notorious user called Ash who with the help of his friend Pikachu, decided to write a script which spams with random and lengthy usernames and emails on the signup page's endpoint(before the spam filter could block them).


Learnings from the example - Both devs tested their own code. Code worked in their context. Things still went south... north... the House of Stark... Jeez... this is hard. You got the point, right?

Had "Jessie" written code(specs) for the actual code which asserts the limit cannot be more than(say 6 chars). "James" wouldn't have been able to deploy the code change because of the assertion failures during the CI process.

Which means while we just run the code and verify all the scenarios by ourselves is a good thing, writing those thoughts(scenarios manually tested) down in code(specs) is much better.

This change in mindset leads to:
  • Increase in productivity because other devs wouldn't have to worry about breaking a flow unknown to them, as the specs would tell them by turning red.
  • Makes it easy to change code without worrying about breaking the behavior of the functionality.
  • Saves more time than manual testing - YES. Imagine testing each field's behavior yourself after every code change, and then imagine just running specs which already know what all to cover. Now, imagine others in the team, who don't have to go through the same fields testing manually who can just run those already crafted specs. Hence the bullet point 1.
  • Specs often lead to the self-documentation of your code.
  • Confidence in all of your deliverables.

Comments

Popular posts from this blog

How I started my career after graduation

Rails 4 flash messages using Twitter Bootstrap 3

The Observer Design Pattern in Ruby!!