Create a global method with signature btmark(message as String) that pushes each new message to a global stack variable. The global stack variable should be reset before running each test. Upon test failure (including errors, etc) print the contents of the stack. This could be used in both production and test code as follows:

Function something(input)
  btmark("starting something")
  ' do stuff
  btmark("something started")
  ' do more stuff
  '... etc
End Function

Function test_something(t as Object)
  btmark("testing something")
  something(generateSomeInput())
End Function

Done correctly calls to btmark could also replace some comment documentation, alleviate some of the pain caused by Brightscripts lack of a stack trace, and serve as an alternative to littering your code with print statements you intend to remove later. By only printing the message stack on test failure, your test output is not filled with irrelevant output. It would be fairly trivial to strip calls to btmark() from production code using a regexp.

Hello,

I am using your test framework in a app and the legal team wants to know how it is licensed. I noticed that you haven't stated a license anywhere. Can you add one? MIT is a good simple one that will protect you. (http://opensource.org/licenses/MIT) Thanks,

using a suffix allows the file and its related test to be listed next to each other in IDE directory listings, etc.

Mark, I'm quite curious what your opinion is of the BrightScript unit testing framework which Roku released very recently as a beta at https://github.com/rokudev/unit-testing-framework.

allow users to create reusable assertions by calls to some global method

addAssertion("assertIsAwesome", function(args): ... : end function )

This would populate some global associative array with methods that would get copied to each new t parameter passed to test. It should fail if users are accidentally overriding an existing method (maybe an optional force parameter to allow overriding?). It would also require some documentation on how to correctly fail an assertion so behavior remains consistent with other methods.

Since AAs are stored internally as pointers, they can contain references to themselves without requiring infinite memory. However, the current method of checking equality (check each k/v pair for equality, recursing if the value is also an AA) will enter an infinite loop.

Although this might sound like an awkward edge case, it's actually very common with the introduction of Scene Graph. All Scene Graph nodes implement ifArray (meaning they will be tested and prone to the same failure case as regular AAs). They also all have a focusedChild field, which -- while intended to be an internal field used for triggering observer callbacks only -- is freely readable, and nodes with focus have this field set to themselves.

Sample test cases:

sub testSameCyclicAA(t as object)
   x = {}
   x["key"] = x
   t.assertEqual(x,x)
end sub

sub testDifferentCyclicAAs(t as object)
   x = {}
   y = {}
   x["key"] = y
   y["key"] = x
   t.assertEqual(x,y)
end sub

Telnet output:

ERROR: testSameCyclicAA
----------------------------------------------------------------------
Unknown Error:  223

======================================================================
pkg:/source/examples/test_examples.brs
ERROR: testDifferentCyclicAAs
----------------------------------------------------------------------
Unknown Error:  223

For example: If I'm using t.assertTrue(...) multiple times in the same test, I currently have no way of knowing which of those assertions failed. An expanded syntax of:

t.assertTrue(value, message="" as String)

would allow for easy differentiation.