Practical TDD in LiveCode

Peter W A Wood peterwawood at gmail.com
Fri Nov 4 23:33:43 CET 2016


Richard

> On 5 Nov 2016, at 01:51, Richard Gaskin <ambassador at fourthworld.com> wrote:
> 
> One of many interesting discussions in our local LC User Group meeting last night was from a relative newcomer who asked about TDD support.
> 
> I was able to tell him we have an assert command, and that many developers have a wide range of ad hoc test harnesses in use.
> 
> But what I couldn't point him to is a single harness framework in our community suitable for broad use.
> 
> Is there one?

People’s opinion of what is needed for TDD differs widely. The so called xUnit testing frameworks are generally quite basic (test specification, assertions and test runners) but suffice for many people. They typically cannot be easily used to test GUI code. Other testing frameworks, it seems especially in the JavaScript world, extend much farther with test doubles, code coverage, and testing user interfaces via the browser.

I have published a simple test framework, Mini-Test. It can be used to test both LiveCode handlers and GUI interfaces. (This is latter is a credit to LiveCode’s features not me). It is rooted in MiniTest, the testing framework included with Ruby. It does not include test doubles, code coverage or performance testing.

LiveCode, the company, has a test framework but, personally, I found it too complicated for my own use. I felt something written wholly in LiveCode would be easier to handle.

If you want to take a look: https://github.com/PeterWAWood/LiveCode-MiniTest


> If not, what would it look like?
> 
> How granularly should we write tests?  How much value is there if the writing of a test takes longer than writing the thing being tested? Should we write a second test for when a handler in our core business logic is integrated into a GUI, where the varieties of things that can happen with input and events is much broader?  Should a good harness simulate GUI events?  If so, how to make sure they attempt sufficient erroneous inputs to ensure the scope of our error handling?  How do we chain tests into a comprehensive automated "Test All"?
> 
> So many questions...
> 
> How do we make one good test harness that answers them all, at least reasonably well?

I feel that the LiveCode engine makes it extremely easy to write a test framework that will do all of the above. It just needs a little thought, such as designing a set of commands to automate user input simulation, and a little work.

Regards

Peter


More information about the use-livecode mailing list