2

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?

1
3

The point of doing TDD and BDD is to use tests to

drive

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)

enter image description here

5
  • I've been in projects with code developed before the testing (manual, then automated). In this case, unit testing were still needed?
    – Rasshu
    Apr 15 '20 at 12:29
  • 2
    They should have been created. The question now comes up - will this code be changed? and if it is changed, will it break functionality. If it breaks functionality, how will we know that? By poking the final result through the UI? Code without unit tests is also code that doesn't get refactored (same scare of breaking it). Code that doesn't get refactored (but does get changed anyway) is code that rots in the most nasty fashion. Apr 15 '20 at 12:32
  • In one of my past experiences as a developer, I didn't do any unit tests in a specific project. Software was entirely tested using Selenium and Protractor, but it was possible because every feature was linked to UI.
    – Rasshu
    Apr 15 '20 at 12:48
  • In that case your protractor tests (protractor) were probably your unit tests. Unit tests that are UI tests are a bit of a headspin on the traditional 'unit tests are backend only' but in today's environment and UI code they can indeed by 'UI' Unit tests. Apr 15 '20 at 12:50
  • 1
    btw, lack of tests or crappy tests (like true == true) are very common and may indeed dominate the industry. I am certainly pushing ideal and best states. I like to do that. Apr 15 '20 at 12:51
1

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.
1
  • Your last bullet point is your only option for existing applications whose code was not written for unit or integration testing. If the application is a giant ball of spaghetti code, then automated UI tests is really your only option. They execute slower than unit and integration tests, but it is better than nothing. Apr 17 '20 at 18:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.