In this post I’m gonna dive into one topic that a lot of people are struggling or are afraid and specifically testing on our code. Testing should be an important part of any major project you’re working on and still a lot of people didn’t do it because it looks too complex, too unclear and so on.
We’ll take a look at what exactly testing is, why we should do testing and of course, most importantly how to test our code and we’ll learn that there is no reason to be afraid.
As a self taught developer who learn and do practice whenever I can, I know we don’t always have time to practice by creating huge projects. But, actually it’s pretty easy to get started with testing, so let’s dive in.
“ Now what is testing ? ”
Testing, when you hear it for the first time, sounds pretty obvious pretty straightforward, we are writing an app, creating an application and we simply test it, right? we had a feature then opening the browser and we testing our application and it will continue to work even you do add other kind of testing.
So testing manually still is something that makes sense you want to see your application run. So in the end the idea always present, that we have our code and we have some expected result, so if we write some code and then we go into the browser and test this code. We have some idea, what should happen we want to open that pages, we want to add something that if user clicks on that button something must happen.
So we have the expected results in our minds and then we just need to simply test our application and if we succeed, we are fine with that, we will modify our code and fix the issue or adjust it the way we want. Short story, testing is an activity that led you to know that your feature or application working just as you want.
Well,. the idea of javascript testing or code testing is to written automated tests, so that we don’t have to manually test everything in our application. Until now we probably still test everything manually but automated tests can be run whenever we change something in our code to see if that affects any part of our application without testing everything manually. One of the major benefits of writing test is we can instantly see breaking changes where issues in our code, always act as good bug reports when they fail, by changes that occur in our code.
Let’s start writing one kind of test, for that I set up a small sample setup step here and of course you just run the npm install in the terminal to manage all the dependencies I have here, I don’t have many dependencies just use mocha, chai & supertest in my package.json file and then we have a very simple test here.
Note: We’ll only be using this in development environtment, so use
save-devto keep it in your devDependencies, if you want to add other dependencies.
For example, we’ll make a folder for your all scenario tests, for the first time we should create a file inside that tests/api folder called test.js. This file aims to register the files containing the scenario tests, so let’s add the other scenario test which is we group by folder into our variable testsDir. With all of the libraries, including the mocha mentioned above, let’s have a looks like at the example below.
Note: Yap! this is using mocha programmatically, documentations is here for more custome options.
Then we create new file on same directory tests/api called request.js for handling event request, the request which will often be used. Let’s require the modules we need to make request. First, we’ll require('supertest').
The End step — Working scenario Tests
Here’s a short example:
Note: Passing arrow functions (“lambdas”) to Mocha is discouraged. here the documentation.
Principles ☕️
> tests should test one thing only
--> test one logical assertion
--> don't mix assertions of state and collaboration in the same test
--> modifications of production code should only break related test cases
> each test should be self-contained, including data
> ensure tests are independent of each other
> don't refactor with a failing test
> organise your unit test projects to reflect your production code
> keep your tests and production code separate
--> do not use production data and code to test production code
> if your tests are difficult to write or maintain, consider changing the designhttps://github.com/whitehorse0/refactoring-developer-habits/blob/master/02-outcome-of-collation/tdd-manifesto/tdd-good-habits-manifesto.md
Simple tests are better tests.
Although the structure looks complicated, we try to find the right way and tools or frameworks to make testing that matches the reality for our API backend. Here’s what we choose to do with.
Before we can run our test in the terminal, we need to set a script in our package.json.
Now, we can jump into the terminal and npm run test. You should see our test running and passing.
Note: And also you can create any test you want to ensure a smooth delivery and integration, especially if you use CI/CD.
“ And why we should to automated test ? ”
So question why we should to automated test, we want to get an error and if some change has break our code, we want to see that immediately without us testing everything manually, we might still do manual testing but it’s still worth a lot to have a suit of predefined automated tests that we can run to quickly see did this change break anything. Well with well-written tests we’ll get the answer right away we’ll also save time if we don’t have to test everything manually over and over again and we are all forced to think about possible issues or bugs when writing our tests we have to think about what do we want to test how do we write a test that makes sense.
I hope this post gave you a nice introduction to the one of type of tests we have and why we write them and later i’ll have more post on testing where we also write a little bit more advanced tests but this post hopefully shows you what tests are and how will you create them and what their advantages are hopefully see you in future post. Hopefully this gives a imagine on our coffee break.
— Thank You.
