Fast test, slow test

I found this video quite interesting, here some observations:

  • Why you test? Tests are preventing regression, fear (enable refactoring), bad design.
  • In the video the guy is talking about System tests. The meaning is quite generic for integration and/or functional tests. Normally they are not as fast as Unit tests.
  • If every time you change the code, you have to change the tests, you have clearly problems with tests
  • A way to measure how our test is unit is to measure how many dependencies we have in every of our tests. Every dependency increase the probability to fail the tests if external code is changed, and when it fails cannot tell you exactly where.

Reasons to fail the test strategy:

  • Use selenium as primary test suite – slow – no possibility to use TDD
  • Unit tests are too big. Studies have demonstrate that testing time is growing exponentially from the start of a process development.
  • Write fine grained tests around legacy code is a bad way to design tests.

Suggestions:

  • 90-95% of Unit tests – 5-10% Integration/Functional tests
  • Quick unit Tests allow you to do TDD. If it has to fail, it has to fail fast.
  • When unit tests are failing, they are pointing the fine grain problem, if this is not true, they are not unit tests
About these ads