A Good Imagination and a Pile of Junk

This afternoon I punched through a major wall (a couple posts down) that was preventing me from doing what I wanted to do here. I’ve been working (at about a 33% pace, what with all the hippy taunting and such I’ve been doing. It IS Saturday Night after all.)

The goal is in sight. I may very well be able to simplify this some more. But here, WITHOUT MACRO MAGIC is the first “live use case” of my C++ unit testing framework.

void test_test()
{
assertEqual("Hello World!","Hello World!");
}
protected:
virtual void register_tests()
{
register_test("test_test",&MyTestSuite::test_test);
}
};


The goal, more clearly stated is to be able to create an xUnit test class with “simple as possible” method tests. C++ being C++ means you must intentionally register the methods themselves.

Yes, the register method is messier than I’d like. I could get rid of the “test_test” parameter by using RTTI but frankly, the farther I can get without opening that can of worms, the better.

Yes, the constructor is a bit messier than I’d like. Currently it’s “the easiest thing that does the trick.”

People who understand C++ will at least get why I’m doing all those things.

Now, more cleanup, more of the framework’s unit tests migrated into the new suite architecture and a few more bits of functionality.

The goal is a production-ready release on April 1, with documentation, etc.

Oh yeah, the library’s about 10k spread across 2 header files.

I just posted this to the Software Craftsmanship group/list a couple minutes ago.  Thought I’d post it here just in case.  It frustrates me that I don’t write better.  But the only way to do it is to do it, so I’m going to do more of it.

(err… I posted the below thingie in response to J. B. Rainsberger’s msg here.)

J. B. Rainsberger wrote:
> Hello, folks.
>
> I think the subject line says it all. I believe that a focus on
> software craftsmanship without a similar focus on becoming an
> entrepreneur wastes valuable energy. Most companies will never respect
> the level of craftsmanship you want to attain, so you’ll need to make
> your own opportunities. Whether you start your own business or don’t,
> I believe you need an entrepreneurial spirit in order to turn your
> passion for craftsmanship into better day-to-day work.
>
> What say you? Full of shit? Bang on?
>
> Take care.
>

I’ve been rolling this over in my head a bit and something’s not quite right.

I certainly do think this J.B. is right about the state of business and their understanding.

BUT

If internal customers aren’t going to respect a certain level of craftsmanship, why would external ones?

Think about what’s been going on in the past few years in our industry. It’s perfectly clear to me that WE don’t even know what the hell we’re doing. I don’t mean that we’re a bunch of hacks. But that we’re trying to work out what good software even IS. Agile practices as a widely accepted notion is what, 5 years old at the outside? (people “got it” earlier, just read Kernighan & Plauger’s “Software Tools” book and tell me it isn’t agile.)

This is a young field and because it’s one of the few crafts that works with zero raw materials, there has been no material cost of waste. It is simply not obvious what is bad product and what is good product. If you have a thing of tin and a thing of steel, senses you’ve been developing all your life tell you pretty quickly which one is going to hold up and feel like a more substantial “better thing.”

So a couple very fundamental motivations out of which true craftsmanship evolved simply don’t exist in our field. Throwing something together that just worked well enough has been expedient for the last 40 years and it’s only in the last 10-15 or so that we’re starting to understand the notion of technical debt, seeing what it’s really costing us and our customers.

Add to that the speed of advance in this arena. New languages, techniques and technologies du jour (Client Server, Push, Fuzzy Logic, Data Warehousing, Thin Client, yadda yadda) all of which were seized upon as panaceas which failed to deliver, to the unending and increasing frustration of our customers who began to see us as just wanting them to pay for toys for us to play with.

So now here we are. We’re starting to realize what a horrible fog we’re in while groping our way around the elephant of craftsmanship, trying to replace the natural impetus of material waste with best practices and discipline. We’ve started wrapping these ideas in packages of nomenclature that can be sold and talked about. And It Is Good.

But think about our customers for a minute. They’re going to look at all this, hold their breath and mutter ‘oh here we go again’. By all estimations, they’re right. What possible reason would they have to think anything else? And how are we going to respond?

Well, we get to pick.

I don’t think there IS a good answer to that. It asks people who have very little attachment to the inside of the software development process to understand an evolution in our field that’s only beginning and that we don’t understand very well ourselves. At the same time we’re telling them that what we’ve been delivering is probably an awful lot worse than we had previously realized. Who the hell do we think we are to have any expectations that a product customer is going to accept that?

What we can always do is to write software better. No matter how intractable the customer seems, there’s always room for personal improvement through diligance and hard work. You can always clean the code a little more. You can always code for testability. You can always leave a code base better than you found it. You can always have out of band converstaions with QA people, asking what would make their lives easier. If the shop “doesn’t believe in unit tests” then keep your unit tests on your box. There’s always room to pull and ground that can be gained.

We work in a world where you can’t hold up a good thing and a bad thing and tell the difference by visual inspection. You can only tell over time what is strong and flexible, and what is brittle. So it falls to us to create a good thing instead of a bad thing and to do so consistently such that the difference will eventually be obvious.

We are doing all the right things. Sure it looks like floundering around in the dark. But that’s only because we’re floundering around in the dark. It’s a part of the process.

Flipping the bozo bit on our customers, whether they are internal or external, is simply not useful.

I’ve dusted off my C++ unit testing framework as it’s been a bit underfeatured for use on a couple projects I’ve been working on.

The fun part is that it’s the ultimate TDD dogfooding project as I’m oscillating between the tests and the framework itself as it evolves.

Frankly I don’t consider what I’m doing to be re-inventing the wheel. Every C++ unit test framework I’ve tried has thwarted me in some way or another; most frequently in the name of making it easy to add a test via macro-magic.

I just don’t care so much about that. I can type. Besides, the result of having ‘the simplest possible add_test line’ is usually a bunch of crap in the test framework that I just cannot in good conscience abide. Hey, if that’s your goal… awesome. Rock on with your bad self.

If I wanted everything to be a one-liner, I wouldn’t be using C++ in the first place.

My real goal with this is to have a framework that’s as rich as reasonable while using standard C++ (requiring a mature compiler. It’s 2009 for chrissakes, you need to support the language) and keeping the framework to a couple (at most) header files. That’s it. There shouldn’t be anything to getting the framework in to place besides:

#include “testfw.h”

and including your test driver shell.

So we’ll see. It’s ambitious of me to try and simplify this down that far I know. But I’ve only got a couple problems left to solve before I’ll have something worth sharing. HOPEfully I’ll maintain the requisite steam to get that out in a few hours. But I’ve an awful lot to work on today.

It’s going to be a bit before it’s got a nice spit-shine on it. But in the meantime…

UPDATE: 7 hours later I have a reasonable TestSuite class. I’m pretty surprised that there are less than 30 unit tests for it which really cover the thing pretty well. I have yet to add recursive suite support (suite of suites.) And I need to templatize my assert functions, they’re stupid the way they are. But it’s more than serviceable at the moment. Definitely not the worst code I’ve ever written.

I’m spent.