Comments by "Ton Bong" (@tongobong1) on "Are You Chicago Or London When It Comes To TDD?" video.

  1. The best thing to do with London style unit test is to delete them. It is better to have no unit tests than to have bad unit test that London style promotes.
    3
  2. I am a bit disappointed at you Dave that after all this time you still didn't find out that London style unit tests are just terrible for projects. Unit as you said is not a class and it is also not a piece or pieces of code. Unit is a unit of functionality and it can be implemented by many objects of different classes or just by a single function. London style is a great example of how NOT to do unit tests. Tests know way too much about internal implementation of a public interface that users can see. You mentioned the injected objects but what about objects that are internally created by a class whose functionality we want to test? Should we mock all those internal objects and should unit tests know about them? Of course not. The question you should ask is what is the purpose of unit tests. 1.Unit tests are protecting the implemented functionality from bugs that can appear after we change the code - extend it or refactor/redesign it. The last thing we want is to get false failures of unit tests because we changed the internal implementation while the final functionality works as before - as expected. 2. The other purpose of unit tests is to get the documentation in code from which we can learn how to use the classes. It is much harder to understand unit tests that have mocks and even worse those that use mock libraries than just plain straightforward unit tests. So London style unit tests fail at achieving both goals. I can tell you that the best programmers at the top software companies like Google and Facebook don't write London style unit test - only "classical" unit test with very few mocks - less than 5% of unit tests have test doubles. Finally if there is piece of software that is hard to test with classical unit tests like web app that is using database then this is a sign of a bad design. We should separate business logic from database access right? We don't need mocks to test business logic that is properly separated from database or filesystem...
    2
  3. You can test IO with integration tests and keep it separated from business logic that you can test with unit tests without the need to mock anything - if you have a good design.
    2
  4. Don't use London style because it is terrible. Integration testing is testing outside the process like access to database and filesystem and when you test more units of functionality in a single test one after another. Example of integration test is: login, creating a record, changing the record, removing the record and logout in a single test.
    1
  5. Yes it is better to write your own mocks and to write as few of them as possible writing classic unit tests. London style is a terrible idea.
    1
  6. Exactly! London style was invented by programmers who have no clue about unit tests.
    1
  7. Yes London style tests are too granular and this can lead into huge troubles when changing/refactoring the implementation details so this is why classic tests are far better than London style tests.
    1
  8. You should study London and classical style unit tests in depth and then you should expose London style as a terrible idea that is killing many projects.
    1
  9. Just use as few mocks and other test doubles as possible and don't use any mocking libraries and don't write London style unit tests because they are terrible idea.
    1
  10. Yes unit tests are great but you should know how to write them and you should also know that London style unit tests are terrible idea.
    1
  11.  @marna_li  top down from interface is a good way to start. Just don't let the top down approach spoil the design of your project. You should remove dependencies from lower level business logic as much as possible and put them to higher level simple controlling logic like GUI...
    1
  12.  @robocodeboy  I must warn you that in memory dbs can give you a lot of trouble because they are not compatible with the persistent dbs. You should separate business logic from db access logic and test the interaction with an empty persistent db in slower integration tests. You test business logic with fast unit tests.
    1