This is the biggest release yet, with 17 entries in the history list!

I've emphasized on inline editing and added a lot of features and fixed bugs related to that.

Get it from the Download area.

I've made a simple user manual for Tester which can be seen here.

In Tester, if you double-click on a function mark entry, you'll see a new window with a better view of the marked and probed variable.

The same happens if you click on a watched variable.

If you double-click on an entry in the result list, the Tests window, if not already opened, will open and jump to the entry, so you can quickly change it.

Note that since the OSX version of REBOL still doesn't support double-clicking, you're screwed for now. I'll make it respond to alt-click at some point.

Tester has a very powerful feature (at least I think it is, plus I'm now forcing you to read the rest of this blog entry) called Function Marks.

Basically Function Marks is PROBE on steroids. It's used in almost the same way, except that data is channeled into a list view inside Tester, rather than blurped to the console to be easily missed, forgotten, etc. Also with this, it's easier to study program flow.

Instead of calling PROBE, you call MARK. MARK requires an argument, which can be a number, a word or anything that can be used as a label. This label is displayed in the list. When you use it like this, it doesn't return values from the function though. This gives you more freedom to place the mark wherever you want, removing the requirement of a return value.

You can use it directly when entering test cases or in the program code of your external program (Tester is still very buggy and you may see odd requesters and sometimes the Function Marks list view display trashes).

The following examples were entered directly in Tester as test cases.

An example of how I like to use it for testing program flow:

this: true

mark 1

either this [

  mark 2

  right

][

  mark 3

  wrong

]

The result will look like this:

Changing a variable will change the program flow:

this: false

mark 1

either this [

  mark 2

  right

][

  mark 3

  wrong

]

The changes are recorded:

To get some data from MARK, use the /prb refinement:

mark/prb 'time now

Notice that I used a meaningful label here rather than a number.

It will appear like this in the Function Marks list:

Why are function marks cool again? Because all marks are stored for each test entry, so you can study program flow for different inputs to a function.

In the result list, you'll see the following:

Each case counts the number of marks so you can easily find them.

I think this is pretty cool.

What does Tester do?

• 
  
• Tester runs sequences of program code. Amazing.
• 
  
• Tester runs sequences of program code loaded off disk. This code can be your own. Even more amazing.
• 
  
• Tester does things in the background to store variables, that you can probe within your code, using a function called MARK.
• 
  
• Using this function, you can also study program flow in your function, under different circumstances.
• 
  
• It provides you with a multitude of bugs, since it is far from completed.
• 
  
• Like most other REBOL apps, it runs on MacOSX, Linux and Windows without modifications. How many weeks of development did I just save?
• 
  

What does Tester not do?

• 
  
• Tester doesn't do profiling. It's not suited for performance testing.
• 
  
• It doesn't improve your love life.
• 
  
• It also doesn't store more than one fixed project on disk for now.
• 
  
• Function marks can't be placed automatically.
• 
  
• You can't yet watch variables inside objects
• 
  
• It doesn't exist in its own context, so if you overwrite a Tester variable, it's likely to crash or go haywire.
• 
  

What will Tester do in the future?

• 
  
• Tester will be able to divide test sequences in stages, so you won't have to sift through 1500 lines of test code when editing very large cases. If you know how a multi-stage space rocket works, this is similar.
• 
  
• Allow multiple projects.
• 
  
• Allow you to import projects from other developers to set up a specific test suite in a snap.
• 
  
• Let you set up expected results and compare those with the actual results from the test.
• 
  
• Get a much cooler name than Tester.
• 
  
• Exist in its own context, so it won't crash when the wind blows outside.
• 
  

Riddled with both bugfixes and a few new features! It can be downloaded from the download page. The history of changes is there too.

This is required for Tester, which also can be downloaded in a very early prototype from the download page.

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...