React.js TDD

In this TDD case we will use React.js and when I was working in this project I found that is very important to have the right version of dependencies installed, or it will not work, and many other developers were reporting the same problems for that reason I will start providing the “package.json” file with the versions of the dependencies that will make your testing experience, much better.

Now that we have the right set up lets start creating the file tree, and here is a picture of the one that I use in this case.

Here is the test code:

Now run the test with the Terminal command: sudo npm run test

And it fail, that is what it should happen this is TDD. 1st fail then Succeed, and now here is the code for this code to pass, the following code will test if the file “App.js” renders and will create a snapshot of the file.

The following is a picture of what you should see as feed-back that the test has pass.

and there you have it, this is the basic code template for React.js TDD from here create more components, test and create using: React.js + TDD.

Category: TDD | Comments Off on React.js TDD

Unit Test

Unit Testing can seem too much work, or too tedious, because is writing several test for each Unit (component) of the project, but this is very important work, here is an example of other people doing unit testing

Here we have two pilots doing the check list before the fly, and they actually go system by system making sure that all of them work, because it only takes one system fail to bring the whole plane down the hard way.

Imagine what would happen if one pilot never check the systems and the plane goes down, if the pilot survives, would you hire that pilot?

The same logic can be use for Web-Applications, and its developers, would you hire a developer who’s websites keep going down?


To make sure that our projects stay up the cloud, we test it component by component before we deploy to the cloud.

Now that we agree that this Component testing is important lest learn how to do it.

In unit testing we write the code to test a unit before we write the code for the unit.

— The code for this post is on GitHub: LINK

in the following example we will create a unit that will add two numbers.

First we will create the project place and the test code, and then we will write the unit code.

Here are the Terminal Commands to create the project and load the Mocha test framework.

After those changes your file: package.json shold look like

Now time to write a basic test.

In the file test.js write the following test.

Then we go to the terminal and type the following command

This means that we successfully run our tests and 0 of the tests pass, 1 fail, the next step is to create the code that will make this test pass, so in the file: math.js write the following code

Save all the changes and now lest go to the terminal and runt the test again.

Congratulations the test pass, now lest write another test for the same unit in the same file: test.js, in this new test when given the numbers 5 & 6 the unit should return 11, but it should do this without failing the previous test. so here is how the files test.js & math.js will be modify.

After we modify this files then we run the test in the terminal:

Congratulations the two test pass, now the next step would be to write as many tests as you think.

in the last test we are using the expect method.

Category: TDD | Comments Off on Unit Test


Why we do Test Driven Development?

Under the TDD (Test Drive Development) principles we create the test case scenario for a unit of code, BEFORE we actually write the code for the UNIT, this might seems backwards at first, but it actually makes sense, because in the real word this is how it works.

Let me explain what I mean for in the REAL WORLD, here is an example.



In the previous video, there is a function that the robot need to perform, and a series of challenges (Test) that need to be accomplished in order to wing the prize.

  • Get the robot to the Moon
  • Find Ice
  • Survive 1 Moon night =  2 Earth weeks of really cold temperatures
  • Find  artifacts of previous explorations

This challenges (Test) are created by mother nature, and the engineers know that the product that they will design need to pass those test, or in other words, the engineers did not create a robot and then see what it can do, they know what should be the results and performance of the robot, in the physical world of matter where we live.

In the previous example, the test (Expected Functionality) already exist, and let me give you an example, the Moon already exist is there, the robot just needs to get there, so the engineers just need to create the robot and spaceship that will get there, the test was created by mother nature millions of years ago.

is not like, look we create a robot, now lest create a moon and see if it can get there, the moon (the test) existed before the robot was created.


In the Digital world, the one of 0’s and 1’s, there we are creating that one as we go, and for that reason we need to create the tests before we create the code.

this is one of many reasons why we do the TDD

Here is an article that explain other reasons why we should use TDD. LINK


Category: TDD | Comments Off on Why TDD