Zero Button Testing turns the OneButtonTesting dial to eleven, to mix a couple of numerical metaphors. DavidSaff'''''''s AutomatedContinuousTesting is an implementation of this for Java in an Eclipse plugin.

The idea is that without pressing any buttons, without typing any keys - without doing anything - your tests run, all the time, and tell you when something's wrong.

Let's consider turning the dials to '''twelve''' -- with ZeroButtonCheckin.

----

This is all about flow, feedback latency, and test locality.

Flow: When something goes wrong - when I've made a mistake - I want to know about it, but I don't want to have to "go somewhere" to find out about it. I want to continue my programming flow, finish that thought, carry on - without interrupting myself or having "the system" interrupt me. I work better that way.

Feedback Latency: I want as little as possible. Just as Zero Button Spell Checking is better than the other kind, just as Zero Button Syntax Highlighting beats the alternative, Zero Button Testing gives me the advantage of showing me my errors as soon as I make them. Trains me not to make them. Minimal feedback latency also rewards me when I fix something, right away.

Test Locality: in doing TDD, I could never figure out where to put the tests. On top, in a bunch? Interspersed with the functions they test? In a separate class? In a separate file? Well, for me, the best place is right inside the function they're testing. That way, the error indication ("correctness coloring") designates where the error is, inherently, without indirection. Furthermore, when tests serve as documentation (and when don't they?), it's nice to have the documentation inline. Find the function and you've found the docs; find the docs and you've found the code.
-- CarlManaster (03 June 2005)

----

One question I have is - which classes/methods to include in the tests above? Including everything you are working on at the moment might lead to InformationOverflow. I know AgileTesting is now developed to a fine art but for me, the SimplestThingThatCouldPossiblyWork is to include test() methods in each class and call them as needed when I want to examine or remember the behaviour of a class and it's methods. Then when creating Test classes I can just call object.test(). Example (Python):

class Tester:
  def run(self):
    s=Scalar()
    v=Vector()
    m=Matrix()
    t=Tensor()
    s.test()
    v.test()
    m.test()
    t.test()

That way, everything I need to know about a class is contained in its definition; I don't have to go on a quest to find test classes and examples somewhere else. 
To me, that is the highest form of ZeroButtonTesting and SelfDocumentingCode.

----

I've developed an application that shows what this might come to be like, with a toy language; you can download it from the files section of the TDD Yahoo group (http://tech.groups.yahoo.com/group/testdrivendevelopment/files/) and you can see an annotated screenshot here: http://www.flickr.com/photos/carlmanaster/9322576/.

''[DeleteWhenCooked: Which file is it?  None of the files on the Yahoo group seem to be a color-coding ZeroButtonTesting test runner.  Did I just miss it?] -- JeffGrigg''

http://photos8.flickr.com/9322576_ca17b472be.jpg

----

I really love the mentioned technique i.e. placing the test code very close to production code (e.g. in the same file). But unfortunately in some projects I worked in they had these programming guidelines requiring the test code be explicitly separated from production code. Even no #defines or #ifdefs allowed.
What are you going to do in this case?

''ItDepends on the language, and on the reason for the guideline.''

----
CategoryAutomated CategoryTesting