Automated Method Testing
Introduction
Automated Method Testing (AMT) is an
evolutionary step with primary appeal to those:
·
Already
relying on Test-Driven Development (TDD) for clean code that works.
·
Hesitant
to custom-code JUnit-style unit tests.
The first-generation
of Java unit testing tools and techniques introduced the notion of
custom-coding; one would custom-code some combination of tests, mock objects
and data. As unit testing tools matured
the emphasis remained on easing the burden of what was fundamentally a custom
approach. In addition, much energy went
into nuanced discussions around what constituted a ‘unit test’ vs. an ‘integration
test’ vs. other labels.
As a second-generation
unit testing strategy AMT focuses on automated pattern recognition and
asserting. A generalized approach might
look like:
·
Establish
a registered set of class implementation
patterns.
·
Establish
an endorsed set of constructor or
static factory method instantiation patterns for each registered
class.
·
Establish
of a certified set of method coding
conventions for each ‘registered’ class.
·
Crawl
through the code base to look for occurrences of a ‘registered’ class pattern.
·
Create
one or more instances of a ‘registered’ class (perhaps with reflection).
·
Assert
(perhaps with reflection) against the ‘certified’ method conventions using
random test data as required.
AMT
Hey wait a minute, what
happened to ‘test first’?
So what happened to the notion of writing
the test before writing the functional code?
Rather than detracting, AMT actually guarantees that the test is
written first! Through the establishment
of registered class implementation patterns and certified method
coding conventions before a single line of code is written … coupled
with the fact that an applicable AMT test stands ready to exercise the patterns
and conventions … an applied assertion
may exist months or even years before the functional code is written.
Perhaps obvious, the observed positive
side-effects of attention to ‘registered’ patterns and ‘certified’ coding
conventions include pattern defragmentation, pattern clarification and overall
design cohesion.
So what happens when
‘uncertified’ or ‘unregistered’ code is authored?
Wow – great question. In that case a first-generation custom-coded
unit test is called for. Several
long-term goals stem from this thought-process:
·
To
mature the AMT machinery so that it can handle a greater percentage of a
code-base.
·
To
reduce the number of patterns (pattern defragmentation) required within an
application code-base.
·
To
influence application architecture so that automated method testability has a
‘seat at the table’ when design trade-offs are contemplated.
How about util (static)
methods?
Static utility methods tend to contain use
case specific logic. Although we may get
smarter in the future, the initial thinking is that such methods are better
tested using first-generation custom-coding techniques.
Working Models
The first proof-of-concept implementation
was TestUtil in 2005 and it was limited to invoking matching ‘getters’ and
‘setters’ on a mutable instance. The
forthcoming ‘CrawlerTest’
set of plugins positions AMT techniques to be applied against an array of class
implementation patterns.
Marvin Toll –
November, 2008