Object Oriented Programmer in Crisis

Code coverage is the glove that fits over unit testing. In order to get an idea of what code coverage follow the link.

I started back into software development with VB6 and then added C#. I love the idea of Test Driven Development (TDD). Reflection in C# seemed to me a HUGE step forward in the tools available to a simple  programmer. NUnit, NCover, Rhino-Mocks, Resharper, and NDepend were my tools of choice.

The paradigm for the use of these tools was to focus from the outside in. What I mean is that you would start at the Integration level and keep adding functionality and refactoring to the lowest type. The problem with this was that I always rolled my integrator/interpreter. I would feed the interperter with a text file:

# Basic Move of Player
Map 3, 3
Player 1, 1
Move n
Move s
move e
move w
Assert 1, 1

# Verify that player stays in north boundaries
map 3, 3
player 1, 1
move n
move n
move n
assert 1, 0

# Verify that player stays in west boundaries
move w
move w
move w
assert 0, 0

# Verify that player stays in south boundaries
move s
move s
move s
assert 0, 2

# Verify that player stays in east boundaries
MOVE e
MOVE e
moVE e
ASSERT 2, 2

See My Tutorial in C#

It is human readable. If you’ve read Pragmatic Programmer you will know what I’m talking about.

The problem with using an interpreter is that I had no way to pin down the text file. Yes I could pin down the interpreter machinery with unit testing, but not the script file. The text file is data not code. Unit testing works on code not data.

In order to pin the script down it would need to be implemented in my source language, but it is very hard to do in C# reflection and all.

It seemed to work pretty good, but I could never shake this feeling that something was missing, until I ran into Greenspun’s Tenth Rule.

The promise of code is data and data is code appealed to me.

So started my travels into Lisp (excpet checking out some AI book when I was in the US Navy).

After reviewing the eco-system for Common Lisp I’ve come to some conclusions.

1. Automation using a tool stack that will let you use unit testing, code coverage, profiling, and integration testing is just not for beginners.
2. Not enough tutorials on building applications (Not Including PCL){Great Book!}
3. More in-depth knowledge of the basics and their implementation in applications. On Lisp is good for beginners. But in the book PG says: “In real programs, the closures and data structures would also be more elaborate than those we see in make-adder or make-dbms.”, what could those elaborations be?
4. Some code that I’ve seen can be Spaghetti Code or a Big Ball of Mud.
5. My own code in lisp can be characterized by item 4.

My goal is to work on item 1.

I’ve worked on adding a fixture to lisp-unit. See My Downloads Section. Now I’m starting on adding sb-cover.

Also I’m going to be getting into ASDF. I think their is a lot of potential their for using it to automate item 1.

Happy Lambda