TDD, where did it all go wrong

General

There are different kinds/levels of testing:

• Unit testing:
  • testing class/method:
    • Helps us to get good design, but coupled to the implementation details
    • Implementation details is going to be changed so that we need to change also our class/method tests => which is expensive and we are lazy to do it => we skip it and the tests are dead
  • Testing behaviour:
    • HERE should be the focus
    • When implementation details have changed but behaviour stayed same, these tests are untouched and we should be free to refactor them
• Integration testing
  • Testing componentization
    • Should be small amount of them
• UX testing

ATDD

• hard to maintain
• Written by business analysts, customers, maintained by devs => nightmare,
• Results in RED state
• What’s the value  having them? They are veeery expensive

 Where did all go wrong?

• Writing UT against classes, methods

Read the book written by Kent Beck: Test driven development by example to understand more, should be like a bible for devs who takes testing seriously

Zen of testing

• Don’t write tests against UX
• UX is going to be changed so your tests have to be changed
• Let UX devs write them

Write tests against surface of module , avoid testing against implementation, don’t couple to implementation, couple to the behavior

Testing should be done using simple steps:

• Get solution to the problem fast
• Don’t solve the problem and engineer together, split them! Then unit testing becomes a part of problem solving task
• Result:
  • Write hacky code just to make test working but DON’T STOP THERE!!! please
• Engineeirng comes later => in form of refactoring!!!!, please, keep it in mind!

Result

DON’T COUPLE TESTS TO IMPLEMENTATION DETAILS!!!!!!

=> you write less tests

Common issue

Ice cream problem:

• Manual testing is too expensive
• Automated GUI tests – we need to rewrite them as soon as UI changes, they are never done, stays RED
• Most useful and the cheapest are UT

Unit Tests – focused on business logic, behavior,

Integration testing: cooperation between components

UI – testing:

• UI widgets testing
• Keep them manual

It should be like this:

Hexagonal architecture

• In the center there is a Domain Model
• Around it there are so called ports – application program interfaces – which makes surface of the system
• Around them we have port adapters (MVC adapter, DB adapter, Notification adapter …) <= this we need to fake in order to
• We test around ports! – public API

TDD/BDD

• Don’t test the things you don’t own
• UT  coupled to the implementation helps us with a design but don’t be afraid to delete them. Tests on higher level should be kept long-term only.

 ATDD

• Can help to clean-up the communication developer vs. business
• Very expensive, business people don’t want to do it

Summary

• BDD is unit testing on the higher level ..
• DON’T mock internals
• MOCK port to adapter

From https://blogs.msdn.microsoft.com/fkaduk/2013/06/14/ndc-oslo-2013-day-3/