{"id":111,"date":"2019-10-16T12:23:43","date_gmt":"2019-10-16T12:23:43","guid":{"rendered":"https:\/\/www.bddtesting.com\/?page_id=111"},"modified":"2019-10-16T12:23:44","modified_gmt":"2019-10-16T12:23:44","slug":"difference-between-unit-testing-bdd-testing-and-tdd-testing","status":"publish","type":"page","link":"https:\/\/www.bddtesting.com\/difference-between-unit-testing-bdd-testing-and-tdd-testing\/","title":{"rendered":"Difference between UNIT testing, BDD testing, and TDD testing"},"content":{"rendered":"\n

When you\u2019re just getting started with automating your JavaScript testing, there\u2019s a lot of questions. You\u2019ll probably see people talk about unit testing, TDD or Test-Driven Development, and BDD or Behavior-Driven Development. But which one of them is the best approach? Can you use all of them?<\/p>\n\n\n\n

I\u2019ve talked to a number of JavaScript developers, and there seems to be some confusion about all this. So, let\u2019s take a look at Unit testing, TDD and BDD, and fix some of the common misconceptions about them out there.<\/p>\n\n\n\n

A korean translation of this article can be found here<\/a><\/p>\n\n\n\n

Unit testing<\/h3>\n\n\n\n

A unit test focuses on a single \u201cunit of code\u201d \u2013 usually a function in an object or module. By making the test specific to a single function, the test should be simple, quick to write, and quick to run. This means you can have many unit tests, and more unit tests means more bugs caught. They are especially helpful if you need to change your code: When you have a set of unit tests verifying your code works, you can safely change the code and trust that other parts of your program will not break.<\/p>\n\n\n\n

A unit test should be isolated from dependencies \u2013 for example, no network access and no database access. There are tools that can replace these dependencies with fakes you can control. This makes it trivial to test all kinds of scenarios that would otherwise require a lot of setup. For example, imagine having to set up an entire database just to run a test. Ugh, no thanks.<\/p>\n\n\n\n

There is a misconception that unit tests require a specific syntax to write. This so-called \u201cxUnit style\u201d syntax is common in many slightly older testing tools. Below is an example of the \u201cxUnit style\u201d, using Mocha:<\/p>\n\n\n\n

suite('My test suite name', function() {\n  setup(function() {\n    \/\/do setup before tests\n  });\n \n  teardown(function() {\n    \/\/clean up after tests\n  });\n \n  test('x should do y', function() {\n    \/\/test something\n  });\n});<\/code><\/pre>\n\n\n\n
But this is just an example of what a tool looks like. You don\u2019t have to use any specific syntax for unit tests \u2013 in fact, you can even write unit tests with plain JavaScript:<\/p>\n\n\n\n
\/\/suite: User\n \n\/\/test: Name should start empty\nvar user = new User();\nif(user.getName() !== '') {\n  throw new Error('User name should start as empty');\n}\n \n\/\/test: Password should be hashed\nvar user = new user();\nuser.setPassword('hello');\nif(user.getPassword() != bcrypt('hello')) {\n  throw new Error('User password should be hashed with bcrypt');\n}<\/code><\/pre>\n\n\n\n
The basic pieces of a unit test are there: Individual tests, which test one thing, and they are isolated from each other. You could use scripts like this to build rudimentary unit tests for your code. But using an actual unit testing tool such as Mocha or Jasmine will make it easier to write tests, and they have other helpful features such as better reporting when tests fail (which makes it easier to find out what went wrong)<\/p>\n\n\n\n
Some think that any automated test is a unit test. This is not true. There are different types of automated tests, and each type has its own purpose.<\/p>\n\n\n\n
Here are three of the most common types of automated tests:<\/p>\n\n\n\n