TDD vs BDD vs DDD

Unit testing

A unit test focuses on a single “unit of code

• Unit tests: A single piece of code (usually an object or a function) is tested, isolated from other pieces
• Integration tests: Multiple pieces are tested together, for example testing database access code against a test database
• Acceptance tests (also called Functional tests): Automatic testing of the entire application

• Unit tests. These tests ensure that individual components of the application work as expected. Assertions test the component API.

• Integration tests. These tests ensure that component interactions work as expected against external artifacts like databases. Assertions can test component API, UI, or the side effects of actions like database I/O, logging, etc.

• Functional tests for each microservice. These tests ensure that the application works as expected from the user's perspective.

• Service tests. These tests ensure that end-to-end service use cases, including testing multiple services at the same time, are tested. For this type of testing, you need to prepare the environment first. In this case, it means starting the services (for example, by using docker-compose up).

TDD

TDD or Test-Driven Development is a process for when you write and run your tests. 

1. First the developer writes some tests.
2. The developer then runs those tests and (obviously) they fail because none of those features are actually implemented.
3. Next the developer actually implements those tests in code.
4. If the developer writes their code well, then the in next stage they will see that their tests pass.
5. The developer can then refactor their code, add comments and clean it up, as they wish because the developer knows that if the new code breaks something, then the tests will be an alert by failing.

BDD

BDD – Behavior-Driven Development –  is a set of best practices for writing great tests. BDD can, and should be, used together with TDD and unit testing methods.

Mocha’s BDD style functions.

DDD

• Development becomes domain oriented not UI/Database oriented 
• Domain layer captures all of the business logic, making your service layer very thin i.e. just a gateway in to your domain via DTO's
• Domain oriented development allows you to implement true service-oriented architecture i.e. making your services reusable as they are not UI/Presentation layer specific 
• Unit tests are easy to write as code scales horizontally and not vertically, making your methods thin and easily testable
• DDD is a set of Patterns and Principles, this gives developers a framework to work with, allowing everyone in the development team to head in the same direction