The “Language Hunting Proficiency Scale” is an adaptation of the ACTFL Proficiency Guidelines for language speaking proficiency. In typical Languge Hunting style, it can understood in a fun, easy, “obvious” way using a party paradigm:

ACTFL Level LH ‘Party’ Level LH Description
Novice Tarzan at a Party Single words, short vocab lists
Intermediate Getting to the Party Ask questions and get answers to get needs
met:  “where/when is the party?”, “what should I wear?”, “what
should I bring?”
Advanced What happened at the party? Recount experience, tell story: “Tarzan drank too much
jungle juice and threw a chair out the window, the cops came and took
him to the drunk tank and I had to bail him out”
Superior Why do we have parties? Discuss social, economical, political, culture nature
of why we have parties

Last month, both Mark Seemann and David Bernstein published a critique of TDD based on whether it promoted good design (or not), using SOLID principals as a litmus test. I felt that the source of their disagreement, agreement and confusion about whether they agreed, came from a ingrained response to value knowledge over fluency.

TDD entails the use of software languages to have a conversation with the compilers and interpreters about testing and code. When TDD is viewed through the language lens, we see that the ability to effect good or bad design has nothing to do with TDD itself, but rather depends on the proficiency of the coder (and their fluency will influence how quickly they can exhibit that proficiency).

Below is a first pass at describing fluency and characteristics we might notice of different levels of TDD practitioners. I started by doing a literal replacement in the WAYK fluency inquiry phrases, described characteristics, then (unexpectedly) realized there was a ‘focus’ associated with each level:

‘TDD’ Level Focus Characteristics
Tarzan at TDD Code Can write unit test that will execute in the runner.
Assert.isTrue().  May start with a test, but soon drifts into
code first development. Tests may break when ‘not on my box’.
Getting to TDD Coverage Uses red, green, refactor cycle. Begins to see defect
reduction, less ‘silly’ bugs.  Tests may have duplicate setup
or code. Long ‘work-flow’ tests with many assertions. Inappropriate use
of file or db resources. Test files and class files may be many to many
relationship. CI build may begin to take a longer time.
What happened at TDD? Maintainability Learns from TDD experience how to write better tests.
Code quality of tests as good as core code.  Effective use of
setup and teardown.  Organizes tests effectively, parity
between tests and classes. Uses mocks effectively. Tests and Code still
seen as separate steps in a process. Tests run in CI in effective time
frame.
Why do we have TDD? Design Uses tests to express intent that causes simple,
effective code to emerge. Sees and factors to patterns effectively.
Strong cohesion between test and class. Can safely check-in after every
cycle.

Please let me know your comments and improvements.

The exciting part is that when we realize that effectiveness at TDD is fluency, it opens the door to using Language Hunting techniques to rapidly teach that fluency.

About these ads