It's never fun to admit that your brain capacity is limited when your pride as a software developer might be at stake. Brain capacity and a long attention span is a Good Thing ^(TM) if you intend to debug your application over an afternoon session and with the intent of having it debugged by the evening.

I had to admit my bad short term memory problem and write a little tool to manage this for me, that goes under the amazing name of Tester. Cool huh? Anyway, this has been a much greater boon than I first thought it would be, when I realized how much data it can juggle for me, so I can focus much harder on spotting the bugs and fixing them, rather than setting up elaborate tests to trigger a specific bug.

It allowed me to identify bugs, I would not have found, unless I was running a late testing stage or early production stage system.

The Amazing Tester

Tester isn't a regular debugger. I actually hate those step-by-step debuggers, because they take a lot of time to rig, set break points and step-step-step-step through that code very slowly and repeatedly. It doesn't cure the problem of derailing my train of thought.
What Tester does is basically just execute test code in sequence at full speed. What Tester makes easy, is to let you watch variables change over time, insert, append, copy and remove tests and to let you quietly analyze the report it generates.

When you specify the file to test on, you can then run the test, and the result list fills up with the results of the test.

Here you enter the testing functions, which are normal REBOL functions.
You can then set, which output you expect, which will be compared against the result found in the test.

Tester reports back if a tested function ran OK or returned an error. Instead of being a fatal error and crashing to the console with a mysterious error, it just continues to run the rest of the tests. The mysterious error is safely stored in the result list.

Once you click on that test code which caused the error, you can see the error itself and the state of the variables you are monitoring.

You can find bugs much easier that way and fix them much faster. The very best part? Change the erroneous code, save it, and press Run Test again to see the change immediately at the spot you left your debug cursor at. Shaves minutes of typing into a few seconds of typing plus one mouse click. Fits my attention span perfectly. Wonderful.

There is also a little function browser, but it's only to help me remember the arguments the functions take, when creating tests.

Simple Function browser and source code viewer.

There's also something in there called function marks as well. What they do, I'll save for the next blog.

Thanks to LIST-VIEW version 0.0.29 (not yet released), it took about 8-10 hours to write and debug over the weekend, so it works kind of OK now, but I want to put more in, such as an ATTACK function, that will attack functions with random or semi-random argument to test them.

If I release it, I'll have to come up with a better name, though...