I've fixed a few bugs in my personal timesaver Tester as well, and I thought it would be a good idea to publish them.

Changes:

• Results are no longer trimmed of quotes and are clipped to 25 kb in length for very large results.
• 
  
• It should now be possible to watch variables inside contexts.
• 
  
• I've removed non-functioning buttons to reduce confusion on what works and what doesn't work.
• 
  
• Full result windows for function marks are now scrollable.
• 
  
• Tests can be rearranged with drag'n'drop.
• 
  
• Tester no longer crashes after creating a new project.
• 
  
• Fixed various bugs that would cause crashes.

Please note that this tool is still experimental. (But it's still a huge time saver for me, and perhaps can be that for you.)

Simply 'do the link at the top of this blog post from a Rebol/View console and you're set to go. Enjoy!

The definition of unit testing from Wikipedia is:

In computer programming, unit testing is a procedure used to validate that individual modules or units of source code are working properly.

For Tester this means that a single unit would be a code entry in the test list, but you can define the size of a code entry to be whatever you want. There are no rules on what you must or mustn't do.

Each entry is simply a block of code that is first LOAD'ed and then DO'ed. If the block returns a result, the result is stored for display in the result list in the main window.

The latest version of Tester will check against an intended result, and report back whether the result is as intended, which of course is part of unit testing.

But real unit testing should offer totally independent tests, and this is where Tester is different, since Tester focuses on testing many parts sequentially and keeping track of results during the test. Furthermore, Tester is not yet able to completely separate each test run, since the tests are done in the same REBOL session as Tester exists in.

If you want to compare Tester to anything, you can consider the REBOL console a hand cranked version of Tester.

Tester has now become slightly more colorful and supports stages.

Stages are a simple scheme for dividing your tests in specific colors. That's basically it, but for longer tests, it's very helpful to separate one process from another.

By entering a test entry, you can choose the color for the entry.

This section is still a little buggy, so when you call up the Test List window, you need to click an entry before it shows as colors.

Rows are also marked now when there is an error.

I can't guarantee much stability right now and the docs are not updated yet, but I've uploaded the latest version to the Download area as tester002.r. The old version is there as tester001.r. Enjoy!

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

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