The purpose of Unit Testing is to verify the correct functioning of single classes or class methods. It should never exceed the bounds of the class, working in complete isolation and returning to the programmer certain proof that a piece of code works correctly.
Integration Tests enable us to identify problems which occur when two units are combined to achieve more complex functionality. Basically, the input and output interfaces of each object are verified, ensuring that the objects can talk to each other.
Test Driven Development
TDD is one of the practices recommended by XP (Extreme Programming) just like pair programming, etc. Its mantra — red, green refactor — represents an iterative process in which you decide what you want too achieve, you write a test, you see it fail, you write the code to make it pass, you do refactoring and then repeat.
In general, the value of the tests is realized with greater confidence in refactoring, thus resulting in better maintainability of the code; the TDD increases this value because it forces us to first think of the interfaces and only think of implementation afterwards, enabling us to achieve better architecture.
Behaviour Driven Development
BDD is an extension of TDD which was born (outside the agile context of XP) to answer the question: TDD is nice, but effectively what should I test? The answer is found in the key word BEHAVIOR, understood as behavior verifiable by the client. In fact, technically, BDD is not very different from TDD; it’s more of a philosophical approach that enables developers and management to communicate with each other, with a shared lexicon that focuses on that which really has value for the client’s business. We start from that which the clients see and which is described in the user stories which, in fact, are the first more external tests of a certain functionality.