BECOME A MASTER TESTER: About Test Driven Development and automated Tests
When I was assigned the challenge to learn how to code automated tests my first thought was:
“Why should I lose my time writing more code than needed? Just write the code that I know, deal with the problem, test in my Postman and if everything is right. Done! Writing more code just for testing is a waste of time!”
It was after that I experienced the famous test driven development that I realized that I was making API’s inefficiently all along! I tell my experience as a beginner in the TDD world in this post. The intention of this text is to share everything that I know about tests. Are you ready to become a MASTER TESTER?
Philosophy
Making an abstraction similar to Kent Beck in his book “Test-Driven Development By Example” programming and beating challenges is like exploring a dark room, you are not entirely sure where you are going, your manual tests are nothing but flashes of light that gives you a glimpse if you are going in the right way or not. Automated tests in this example serves as a flashlight. You can see much clearer, but in order for your flashlight to work you have to make sure it is energized with batteries (which are your automated tests). Automated tests are like this, it gives you a much more lucid insight about the consistency and quality of your software, it doesn’t show you the full picture, but if you feed it correctly with code that automates your exploration, you will be much safer than just flashes of positive tests made manually.
When you don’t know if what you are writing is right in every scenario possible and your code goes to production this can lead you to a kind of fear state. Fear is never good for a programmer. For these cases there are automated tests.
“Fear is the path to the dark side…fear leads to anger…anger leads to hate…hate leads to BAD CODE“
- Yoda
Automated tests gives you a safer feedback of what’s right and what’s wrong in the development. Imagine that you are adding new features and end-points in your API that was bug free. Your tests will show any conflict and with this, you always gonna be safe that you are walking towards excellency when dealing with software development.
Test Driven Development: A methodology
Let’s say that you need to build a new feature in your code, in Test Driven Development, there are three steps to guarantee that your cod is well implemented:
Make a test that fails
Write a code that passes the test
Refactor the code
Like any other methodology consistently used, TDD is simple and practical. To elucidate these three steps, let’s apply this concept in a simple code that receives two integers and return the sum of them. The first step is to build a test that fails.
function test(){
try{
var num1 = 6;
var num2 = 4;
var result = sum(num1,num2);
if (result === num1 + num2){
document.write("TEST PASSED");
}else{
document.write("TEST FAILED");
}
}
catch{
document.write("TEST FAILED");
}}
With this small test in JavaScript, it is already possible to validate if the business rules are right, when you compile the function, the code probably will return an error with the string “TEST FAILED”, once the sum function was not even implemented. With the first step completed, let’s go to the second step: build a code that passes:
function sum(num1,num2 ) {
return num1 + num2;
}With the second step complete, when I run my test, it will indicate that my function was well implemented and that is it! The third step, refactor the code consists only to clean the code so it is more efficient and still passing the tests. Because this example is very trivial, the third step can be skipped.
Automated tests.
When you write automated tests, it’s extremely important that they are all made following your API documentation, in order that your business rules passes the tests and are in as it should be when the software was architected
There are several concepts of tests, in this text we will see three of them:
Unit Tests
Unit tests are essential in any scenario, the code written above is nothing less than a unit test, just execute a function with a given input and see if you get the desired output. Some of unit tests are:
- State: The correct answer was given by the server.
- Performance: The answer was given in the desired time.
- Syntax: The content of the answer was as expected.
- Syntax: The server accepts right inputs.
- Error Handling: The server rejects incorrect input.
- Error Handling: A missing parameter results in error.
- Error Handling: Inserting wrong formats results in error.
- Error detection: Guarantee that several of wrong inputs doesn’t return status code 200 (acceptance)
- Scheme: Verifies if the structure of the answer is as expected.
- Functional: The inserted value gives a logical answer following the business rules
- Functional: The requisition modifies the data sent
- Security checks: SQL injections, authentication failures, etc.
Integrated Tests
Integrated tests approach a group of services in your API as a conjunct and checks if a given input returns an expected answer in a specific end-point. As an example: The users logs in, inserts an item in the database and logs out. Your test needs to make sure if the given scenario goes as expected.
Performance Tests
Given an excessive number of requisitions you analyze the response of your server, having an image about your code’s quality and your infrastructure consistency. With this kind of test you can have an estimate of how many users your API contemplates.
In the end, I expect in the deep of my hart that you guys have liked it. Any feedback is very welcome. Any doubt you can send me a message! :)
