iteration

Testing... Testing... 123...

Episode Summary

This week we talk about writing changeable code, knowing what to test, when to test, and how to test.

Episode Notes

Iteration S05E09

Testing… Testing… 123

Publishing February 18th - Hope everyone had a good Valentine’s Day weekend!

A weekly podcast about programming, development, and design through the lens of amazing books, chapter-by-chapter.

Introduction

• Writing changeable code is an art on which practice relies on three different skills. First, you must understand object-oriented design. Poorly designed code is naturally difficult to change.
• First, you must understand object-oriented design. A poorly designed code is naturally difficult to change.
• Second, you must be skilled at refactoring code.
• Finally, the art of writing a changeable code requires the ability to write high-value tests. Tests give you the confidence to refactor constantly.

Reasons to test:

• Finding Bugs
• Supplying Documentation
• Deferring Design Decisions
• Supporting Abstractions
• Exposing Design Flaws

Knowing What to test:

• “Most developers write too many tests” - OR NONE! hahaha
• Tests should concentrate on the incoming or outgoing messages that cross an object’s boundaries.
• Back to the Kitchen Metaphor - Test that ordering a hamburger, returns a hamburger as expected, not that the kitchen staff turns on the grill or slices tomatoes.
• Incoming messages should be tested for the state they return.
• Outgoing command messages should be tested to ensure they get sent.
• Outgoing query messages should not be tested.

Knowing When to Test

• Write tests first, whenever it makes sense to do so

Knowing How to test:

• Testing Styles: Test Driven Development (TDD) and Behavior Driven Development (BDD).
• Proving the Public Interface
• Injecting Dependencies as Roles
• Testing Inheritance - Test your base class - then include the module to test each of the responses that are in the base class.
• Creating Test Doubles - DiameterDouble - A test double is a stylized instance of a role player that is used exclusively for testing - tend to override the base class in my test helper - I’ve run into silent errors this way.
• Testing Private Methods - interface. These private messages are like proverbial trees falling in empty forests; they do not exist, in a perfect world they do not need to be tested - testing them is a code smell.
• Testing Ducks - create a preferred test interface - mechanic and a guide can both prepare - you can establish a single interface and simply pass the different objects into it.
• Testing Inherited Code
• Testing Models + Objects Vs interface - where’s the balance?

Tests are indispensable. Well-designed applications are highly abstract and under constant pressure to evolve; without tests these applications can neither be understood nor safely changed. The best tests are loosely coupled to the underlying code and test everything once and in the proper place. They add value without increasing costs.

Next Episode - Recap of Practical Object-Oriented Design and New book announcement!

Picks:

NOUN PROJECT - https://thenounproject.com/

**Super Smash Bros Ultimate **

Neil Davis - @Nei1dor

Aaron Kelton