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.