What vs How in Test Driven Development

Example #1 for What vs How


Music sheet is not music. It is the description of music. This is the What or Logical Design.

Music Sheet

Music is played using musical instruments. This is the 'How' or the Physical Design. There are many physical designs for a given logical design. This means a musician can use different instruments at different times to play the music from the same music sheet.

Example #2 for What vs How


John Lennon wrote the song Come Together. This is the What. The examples of How in this case are the performances of :

  • Beatles
  • Aerosmith
  • Michael Jackson

to the same song Come Together.

What vs How


alt text

If you find this diagram overwhelming, don't worry, I will build this diagram gradually in my upcoming TDD course.

Separate Logical Design from Physical Design


Why do we need to separate logical design from physical design? Because it allows us to change implementation without breaking the tests.

alt text

So, how do you separate What from How in our code? Chris Stevenson's TestDox style expresses the subject in the code as part of a sentence.

  • A Sheep eats grass
  • A Sheep bleats when frightened
  • A Sheep produces delicious milk
  • A Sheep moves away from sheep dogs

This can be automatically converted to specifications in code :

describe Sheep do
  it 'eats grass'
  it 'bleats when frightened'
  it 'produces delicious milk'
  it 'moves away from sheep dogs'
end

When you think about the system from outside-in fashion you focus on intent. You focus on what you are doing rather than the implementation which is the 'how'. Now that we understand the difference between the What and How. We know how to write the doc string. But what code should go between the do-end block of the it() method? To answer that question, let's look at the difference between imperative vs declarative programming.

Technique : Seeing at Different Abstract Levels


We can see object and behavior at different levels:

  • At the conceptual level - a set of responsibilities.
  • At the specification level - set of methods that can be invoked.
  • At the implementation level - code and data.

Responsibility is defined as an obligation to perform a task or know information. At the conceptual and specification level we are focused on WHAT. At the implementation level we deal with the HOW

Imperative Programming


Imperative programming is the oldest programming paradigm. It is based on the Von Neumann-Eckley model of a computer. Programs written in imperative programming languages consist of a program state and instructions that change the program state through assignment statements. Program instructions are imperative in the sense of imperative verbs that express a command.

You tell the machine HOW to do something and as a result what you want to happen will happen. Examples of imperative languages are assembly, Fortran, Algol, Cobol, Java, C/C++. These languages specify a sequence of operations for the computer to execute.

Imperative Program = Algorithms + Data Structures
-- Nicholas Wirth

Imperative Programming + Procedures = Procedural Programming

Procedural abstraction and structured programming are its design techniques. Procedural abstraction allows the programmer to be concerned mainly with the interface between the procedure and what it computes, ignoring the details of how the computation is accomplished.

Abstraction allows us to think about 'what' is being done, not 'how' it is implemented. Imperative language constructs : assignment, conditionals, looping and data structures. Flowchart can be used to model imperative programs. For example flowchart for computing Fibonacci numbers.

Declarative Programming


Functional languages and logic languages are declarative. Declarative languages such as SQL, Haskell, Prolog describe the solution space. They provide the knowledge required to get there. They don't describe the steps needed to get there.

You tell the machine WHAT you would like to happen, let the machine figure out how to do it.

Discussion


The tests that we write must be declarative. It should not be imperative. This means no implementation level details such as loops, conditionals or data structure should be in the tests. For an example illustrating how to eliminate loops in a test, read the article Eliminating Loops in Specs

References


  1. Test Driven Development: Ten Years Later by Michael Feathers and Steve Freeman

  2. Presentation by Computer Science Assistant Professor Mary Ellen Weisskopf

  3. A Brief Tour of Responsibility Driven Design. Presentation by Rebecca Wirfs-Brock.

Exercises


1) Does the blueprint for a car focus on What or How ?

alt text

2) Search YouTube and watch the videos for Come Together performed by The Beatles, Michael Jackson, Aerosmith and Elton John


Related Articles


Ace the Technical Interview

  • Easily find the gaps in your knowledge
  • Get customized lessons based on where you are
  • Take consistent action everyday
  • Builtin accountability to keep you on track
  • You will solve bigger problems over time
  • Get the job of your dreams

Take the 30 Day Coding Skills Challenge

Gain confidence to attend the interview

No spam ever. Unsubscribe anytime.