[e12e]

[ed: I feel I should preface this to say that this is very old code, and something I'd normally show to anyone. But since you asked... :-) ]

Unfortunately it looks like the code that was the best (worst) example of what I'm talking about isn't readily available (I have it some backup-archive or other...) -- and my other code is partially restructured based on what I learnt, and most significantly in Norwegian.

However, one example, while not breaking the function-gap, is a small sub-section from the noweb document that reads (this is java 1.4):

  <<src/AllTests.java>>=
  import junit.framework.*;
  import junit.extensions.*;

  public class AllTests extends TestCase
  {
    public AllTests(String name) 
    {
       super (name);
    }
	
    public static void main(String[] args) 
    {
       junit.textui.TestRunner.run(AllTests.class);
    }

  <<testSucceed>>
  <<testTabell2D>>
  <<testBrikke>>
  }

And the testSucceed-section is just a simplistic sanity check to make sure tests can be run/pass:

  <<testSucceed>>=
  /** Testing the test harness */
  public void testSucceed() throws Exception 
  {
    assertEquals(10, 10);
  }

These two blocks, the test setup, and the meta-test go together in a neglected corner of the document, given only a little more priority than the build.xml-file -- while the more functional tests are moved close to the various interfaces (in this case) they are testing (rather than having them too close to the implementations they're actually testing).

So one could say that this gives us injection without an injection framework. Or something. This is basically fixing a naming issue in java, where you need methods to be bound to a class (except for static stuff etc) -- and is an "abstraction free" (at the language level) way of moving things that go better together -- closer together.

Note that the blocks pretty much lacks comments, as they are a bit gnarly to get to work with both java and noweb and javadoc -- but that is more of a tooling issue than anything else.

In this case (imagine 10s of test cases) the tests might be a bit under-documented when seen in isolation. Note that each block actually holds a couple of test-cases applicable to whatever class/interface-pair it tests.

But it gets even more interesting when you're sharing a block of code that implements a binary search on an array-like structure... does make it a little too easy to trip over local variables though.

The full code (in Norwegian) is at: http://folk.uib.no/st05861/inf101/oblig1/ -- it's not very good, but the noweb source and pdf (oblig1.nw, oblig1.pdf) might be of some very limited interest -- and could be contrasted with the java code under src.

This is all from an entry level programming course, the task was given as a pdf-document with some specs and a few stub interfaces -- the resulting pdf essentially interleaves the questions/specs as given, along with the interface stubs -- and builds up answers to each sub-section/point.

The other code I mentioned was more along the lines of implementing binary search for a an array-like interface etc -- basically Abstract Data Structures.