CategoryTesting -- for a list of Frameworks, see TestingFramework
-----
On ChryslerComprehensiveCompensation, we use KentBeck's public domain TestingFramework [http://www.armaties.com], much enhanced to support our evolving needs.

A new unit test is a subclass of TestCase.  It includes a #setUp method which is executed before running each actual test.  The 'running' protocol of the test class contains test methods.  Each is executed sequentially, after running #setUp.  The test manipulates the object it is testing, and then checks results with code like:

    | sam fred |
    . . .
    self should: [testObject size = 5].
    self should: [testObject first = sam].
    self should: [(testObject at: #fred) = fred]

We don't do any special enforcement to check whether each class has appropriate unit tests.  Since we don't practice CodeOwnership, everyone will see what is being done and tested, and it will get fixed.  And social pressure will be put on anyone who isn't doing enough testing.

Our functional tests are run under the same framework, with a lot more support to do all the necessary set up (input files, running a payment workplan, checking output files, etc).  --RonJeffries

-----

We are using the same framework, Ron, and are very happy with it. In fact, I frequently quote the C3 "FourProjectValues" statement about producing as much test script as code. I'm interested in what kinds of extensions to the framework that you have found necessary? I am also interested in the degree to which you actually write the tests first... -- BillBarnett
----
Perhaps the answer to that question is found in this statement: - "Writing tests for all the public methods in Set is a daunting task. However, as Hal Hildebrand told me after using an earlier version of this framework, 'If the underlying objects don't work, nothing else matters. You have to write the tests to make sure everything is working.' "

This seems to imply that tests are written to "make sure" - that sounds like tests written after rather than before coding. (But only Ron can really answer the question)-
-----

I think you are seeing the evolution of a TestInfected developer's perspective over time. The first stage of the infection is the realization that you have to have the tests to make sure everything is working. The second, more advanced phase, is the idea that having the tests first makes it easy to know when you're done, and helps you focus on building the simplest thing possible.

I think of test first programming sort of like "market first" product design. First we develop a product pitch that has sufficient market to be viable. Then we implement the simplest product to fulfill the pitch (To a greater or lesser degree. Hopefully TruthInAdvertising -- or lack thereof -- isn't such a problem in the software world.) -- BillBarnett

See also FrameworkForIntegratedTest