TestSuite>>finishedRun is broken

Problem Description

The finishedRun message follows the same pattern as TestSuite>>aboutToRun, is broken in the same way, and requires the same fix.

This bug also demonstrates that a test case is missing from ZeeTestTest (and, for that matter, from the original Smalltalk unit test test). The test case needs to be created and the bug repaired.

At a meta-level, it seems clear enough that these two bugs are really ONE bug with two symptoms. This, in turn, suggests additional required functionality in the Zeetix environment. It should be possible to express the relationship between these “two” bugs, so that it can be fixed “once and only once”.

At a deeper level, TestSuite>>aboutToRun and TestSuite>>finishedRun are two applications of the same underlying code pattern. That pattern originally delegated each to the clazz. Instead, it should have delegated each to a (missing) enumeration of the contents of the receiver.

This deeper relationship between these two apparently (from the source code) unrelated methods cannot be expressed in a notation-driven environment. This inability demonstrates why the Zeetix approach is needed.

Problem Code

The broken code is the implementation of the instance method (finishedRun) of TestSuite. The current Python implementation (transliterated from Smalltalk) is:

clazz TestSuite:
    def finishedRun(self):

This should be replaced with an implementation that enumerates all tests contained in the receiver and sends finishedRun to each. In Smalltalk, this would read something like the following:

   self allTestCases do: [each | each finishedRun]

The allTestCases method does not currently exist and needs to be created.
To Do

  1. Create a test case in ZeeTestTest that demonstrates the bug.
  2. Modify the code in ZeeTest to fix the bug
  3. Demonstrate that ZeeTestTest passes all tests, including the new one.

2 Responses to “TestSuite>>finishedRun is broken”

  1. Mike Burns Says:

    To make the claim that this relationship cannot be expressed with notation is akin to saying that, say, the iterator pattern cannot be expressed with notation. Scheme does express it through `map’; it’s just difficult in, say, Java or C.

    Perhaps Zeetix is the language that allows for the notion that expresses this pattern.

    • tomstambaugh Says:

      I think we’re exploring the syntax-vs-semantics dimension here. I think, although I’m not certain, that “map”, in Scheme, is a “normal form” — it is part of the Scheme environment, rather than part of its syntax. Your example of the iterator pattern is an excellent choice. It exists in Smalltalk as part of the environment. It exists in Python as part of the syntax (Python includes “map” as a language element). It is missing (AFIK) altogether from Java and C (for/while loops don’t count).

      The “language” of Zeetix, in this context, is still Ruby, Python, Javascript, or whatever binding we’re discussing. A premise of Zeetix is that the creation, combination, and manipulation of these patterns should be as available (meaning things like “convenient”, “editable”, “subject to version control”, and so on) as the expressions (into a programming language) that they generate.

      I’m particularly intrigued by incorporating test-driven development into this paradigm — perhaps something akin to the assertion framework provided by Eiffel.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: