{"id":20795,"date":"2017-10-04T15:09:56","date_gmt":"2017-10-04T15:09:56","guid":{"rendered":"https:\/\/legacy.livecode.com\/?p=20795"},"modified":"2017-10-11T09:28:17","modified_gmt":"2017-10-11T09:28:17","slug":"testing-1-2-28534","status":"publish","type":"post","link":"https:\/\/legacy.livecode.com\/testing-1-2-28534\/","title":{"rendered":"Testing 1, 2, 28534"},"content":{"rendered":"

I really enjoy writing tests. It’s great to ensure that a new piece of functionality will never be broken, or that a bug will never be reintroduced. It’s doubly satisfying when something previously untestable becomes testable, when a certain level of struggle or ingenuity is required to work out how<\/em>\u00a0to test something, or when a test is particularly (perhaps even maximally) succinct.<\/p>\n

I really enjoy writing tests. It’s great to ensure that a new piece of functionality will never be broken, or that a bug will never be reintroduced. It’s doubly satisfying when something previously untestable becomes testable, when a certain level of struggle or ingenuity is required to work out\u00a0how<\/em>\u00a0to test something, or when a test is particularly (perhaps even maximally) succinct.<\/p>\n

LiveCode’s continuous integration had its 2nd birthday recently, and ever since a ‘quick’ test runner was implemented for this purpose, the number of tests and the test infrastructure itself has ballooned.<\/p>\n

To celebrate this birthday, in this blog post I’ll be describing all the different sorts of test we run, and picking out a few of my favourite examples.<\/p>\n

Engine tests<\/h2>\n

The engine test runner uses the standalone engine to execute each test handler defined in the test scripts in its own subprocess. These tests – at least those in the ‘core’ section – are intended to ensure that every single variant of syntax, each of which should have received a distinct code-path in the syntax refactoring project, has a test of its functionality. Ideally, every execution and parse error would also have a test.<\/p>\n

For example, a simple engine test might be<\/p>\n

\r\non TestCreateStack\r\n    create stack \"test\"\r\n    TestAssert \"Stack created\", there is a stack \"test\"\r\nend TestCreateStack\r\n<\/code><\/pre>\n
The TestAssert<\/code> handler takes two arguments,<\/p>\n
\r\nTestAssert pDescription, pExpectTrue\r\n<\/code><\/pre>\n
If the expression passed in pExpectTrue<\/code> is true, the test with description pDescription<\/code> passes. If not, it fails.<\/p>\n
Cyclic behavior error<\/a><\/h3>\n
\r\non _TestCyclicBehavior pStack\r\n    set the behavior of (the behavior of pStack) to pStack\r\nend _TestCyclicBehavior\r\n\r\non TestCyclicBehavior\r\n    create stack \"Behavior\"\r\n    create stack\r\n    set the behavior of it to the long id of stack \"Behavior\"\r\n    TestAssertThrow \"cycle in behavior script hierarchy throws\", \\\r\n        \"_TestCyclicBehavior\", the long id of me, \\\r\n        \"EE_PARENTSCRIPT_CYCLICOBJECT\", it\r\nend TestCyclicBehavior\r\n<\/code><\/pre>\n
What does it test?<\/h4>\n
This test ensures that it is an error if there is a cycle in the behavior hierarchy.<\/p>\n
How does it test?<\/h4>\n
The TestAssertThrow<\/code> handler is a test utility that allows you to test that the expected error is thrown when a given handler is executed. The TestAssertThrow<\/code> handler has parameters as follows:<\/p>\n
\r\nTestAssertThrow pDescription, pHandlerName, pTarget, pExpectedError, pParam\r\n<\/code><\/pre>\n
Its function could be described as: execute handler pHandlerName<\/code> which is implemented in the script of pTarget<\/code>, (with an optional parameter pParam<\/code>); pass the test with description pDescription<\/code> if the error with code pExpectedError<\/code> is thrown as a result.<\/p>\n
The error in this case is “parentScript: loop in hierarchy”, which you can find by checking the execution errors source<\/a>.<\/p>\n
Why do I like it?<\/h4>\n
I must admit, my enjoyment of this test is almost exclusively bound to the simplicity of the error-throwing line of code. It’s neat.<\/p>\n
Why is it important?<\/h4>\n
This needs to be an error because otherwise there would be an infinite loop when trying to find a handler in one of the objects’ message paths.<\/p>\n
Other good tests:<\/h4>\n