Applying TDD Teaches Everything

 |  Writings

TDD is the opposite of covering code by test. Learning it very early and the correct way gives a programmer a deliverance from the darkness surrounding them.

[INFO] Refer to my review of Kent Beck's TDD by Example for more details.

Practicing clean careful correct Test-Driven development builds in you the practical feelings of the immense value. You internalize the grasps of how to study domains, decompose them to parts, feel how to make low coupling and high cohesion - the core of Single Responsibility (SRP) and Separation of Concerns (SoC) principles.

What You Get in Return

Unstuck your professional development as SRP and SoC de-load your brain from the clutter of sloppy code - writing sloppy code with TDD is much more difficult. TDD naturally moves your brain to write clean code 1. Going this way itself will gradually teach and ingrain in you clean code feeling and habits.

What Else You Get in Return

The joy of delivering the code that works from the first time. The default no-defects production state. The satisfaction from product working as the customer wants. The freedom to easily make endless necessary changes that comfortably adapt the product to the market.

What the Business Gets in Return

The professional engineering culture and the team (no negative selection). The reliable product withstanding the market changes. Potentially to stand among the segment leaders. No throw-away code = no throw-away time, product, money.

Sloppy Code

Sloppy code takes all your brain scarce capacity on programming decisions making. Momentarily and in the long run.

No room to absorb details of the current task due to brain overload with unnecessary complexity. No chance to isolate actual problem from that sloppy code soup.

No room in the long run to consistently exercise the profession due to being ping-ponged among debugging present sloppy code, fixing accumulated product defects coming from past sloppy code, sloppy coding the future functionality, depressed by whatever you code is awkward, inconsistent, buggy, .

Change

There will be the first hard mental change - stop coding, start modeling, designing. That must precede with domain understanding, talking to domain experts, requirements clarification, formalization. Now only it comes to designing. That open doors for more, better, different professional knowledge and experiences.

TDD - the ability to unstuck your professional development for the years to come.

TDD Historically

TDD is a core part of everything in professional programming. The part of further Extreme Programming (the book review) movement that later became Agile movement.

TDD (1999) conceptually resides in Design-by-Contract (DbC, 1988 Bertrand Meyer, the Eiffel programming language). Both clarify the "contract" (requirements) upfront to design the implementation. TDD uses "unit testing" approach that informally dates back to 1970-80s and rise of structured programming.

Footnotes

  1. Cleanliness comes from the domain task being well decomposed into good lean objects - giving each one the inputs, outputs and responsibilities that fit the others and not interfere (low coupling, high cohesion). Designing the objects input and outputs from a consuming objects standpoint keep your eye on object interactions making implementation details unimportant. That frees your cognitive capacity. Well-assigned responsibilities draw clear boundaries of object behavior that can be tested in isolation, allowing for implementation details unlimited refactoring while standardizing the object public interface. The list goes on and on. ↩