Casey...

On Thu, Jun 12, 2008 at 2:54 AM, Casey Charlton <casey@...>
wrote:
>>>> error-prone business of constantly explaining how XP's unit tests are
>>>> quite unlike the testing world's unit tests.<<
>
> How are they different???? A Unit Tests tests a *single* unit ...
> anything that tests 2 or more units is an integration test. What is a
> micro test?

A micro test is an automated test of a very small, hence micro, portion of a
code base. It typically has these features:

* It is short, typically under a dozen lines of code.
* It is always automated.
* It does not test the object inside the running app, but instead in a
purpose-built testing application.
* It invokes only a tiny portion of the code, most usually a single branch
of a single function.
* It is written gray-box, i.e. it reads as if it were black-box, but
sometimes takes advantage of white-box knowledge. (Typically a critical
factor in avoiding combinatoric issues.)
* It is coded to the same standard as shipping code, i.e. the team's best
current understanding of coding excellence.
* It is vault-committed source, with a lifetime co-terminous with the
functionality it tests.
* In combination with all other microtests of an app, it serves as a
'gateway-to-commit'. That is, a developer is encouraged to commit anytime
all microtests run green, and discouraged (strongly, even nastily) to commit
otherwise.
* It takes complete control of the object-under-test and is therefore
self-contained, i.e. running with no dependencies on anything other than the
testing code and its dependency graph.
* It runs in an extremely short time.
* It provides precise feedback on any errors that it encounters.
* It usually (not always) runs entirely inside a single computer.
* It usually (not always) runs entirely inside a single process, i.e. with
few extra-process runtime dependencies.
* It is part of a collection all or any subset of which is invokable with a
single programmer gesture.
* It is generally written before the code-change it is meant to test.
* It avoids most or all usage of 'awkward' collaborators via a variety of
slip-and-fake techniques.

Most important has already been mentioned: Speaking of the entire suite of
microtests, its primary role in the overall development effort is as
productivity enhancer, not quality guarantee. (It certainly does impact
quality in a positive way, but that is itself a side-effect, being of course
a key factor in its success at increasing productivity.)

Now, understand me, nothing on that list above makes a microtest not a unit
test. All microtests are also unit tests. It's the reverse proposition
that doesn't hold: all unit tests are not in fact microtests.

Seeya,
Hill

P.S. I'm writing this in a hurry, as I'm on my way to teach, and to tell
you the truth, I'm a little bit shaken up, because as far as I can tell, in
another part of the forest, Ron Jeffries just admitted -- for the first time
*publicly* -- to a deep abiding admiration of my genitalia, and I'm all
aglow. So I hope this note comes off as adding a little clarity, and not
just noising around. If you have further questions or issues, fire away.
Please do temporarily adopt the wikipedia mantra of 'assume good faith' with
me, tho.


[Non-text portions of this message have been removed]