It seems to me it's doing the same job twice, one with mocks and the other without them. Could anyone explain why it's right or wrong?
The point of doing TDD and BDD is to use tests to
the design of the code. This is what unit tests are for and they should mock and stub out dependencies so they can just focus on the code under test.
Once they pass (i.e. code is developed) then you need tests to see if the code works with the other modules and services and dependencies - integrated testing.
You may also want to have a third level of testing in the UI so that the user experience is good.
You may or may not be able to share some of the valicdation code but in reality, in many cases, especially the UI you may need to duplicate the validations.
At the end of the day the true determinant is how much value you place on the value of tests in terms of the customers.
The order should be:
UI tests that fail (BDD) \|/ Unit tests that fail (TDD) \|/ Write application code \|/ Unit tests that pass (TDD) \|/ UI tests that pass (BDD)
There are several reasons which I can think of for why we still need both test types:
- In real life Unit tests do not cover 100% of code. The code has to be designed in a special way to maximize its testability with unit tests.
- Your code will likely use a lot of third party libraries which might produce different erroneous outcome that is impossible to predict
- Quite often (especially the systems with user interface) use generated code sources which are not covered with unit tests
- Your components might work as you expect each in particular but the business goal might still not be addressed when they get integrated
- Unit tests are usually written by devs while integration tests are usually written by QAs. Hence providing an alternative view on expected results which is always useful.
- Sometimes it is cheaper to use the real system rather than to design a valid mock that would reflect all relevant behaviors of the resource.