by
...
Unknown user
In Part 2 of this series I extracted my TXA parsing code into a class for easier reuse.
...
Automated testing is a bit more awkward in a language like Clarion, but still possible.
Using ClarionTest
A few years ago I wrote an application that became ClarionTest, which is an automated test runner loosely patterned on .NET unit testing tools like nUnit. ClarionTest's job is to load up a specified DLL, search it for test procedures, run those test procedures and report on the results.
...
I've included DCL_Clarion_TXAParser_Tests.app in the DevRoadmaps Clarion Library on GitHub. For information on creating your own test apps see Creating a ClarionTest test DLL (DCL).
Testing the parser
In Part 2 I proposed the following test code:
...
I made two minor changes in my test code, adding a second check for the number of procedures and an error check. Here's how the code looks in the embeditor:
This single test procedure with three AssertThat statements is by no means an exhaustive test of the parser class; much more should be done, including verifying that the embed content is what is expected.
...
I can verify my embed data test by changing one line of one embed point in the TXA, which results in a failed AssertThat statement:
You know, there is a template that extracts embeds...
Even back when I wrote the original parser I was pretty sure there was a template that would extract embed points, and Steve Parker finally pointed it out to me: Bo Schmitz' free BoTpl utility can extract embed points from applications. Bo's excellent template does this by exporting a TXA and parsing the result. Sound familiar?
...
Or my code. And wasn't I going to create a utility to view embedded source?
The embed viewing utility
The purpose of all of this refactoring and testing was to have a class that I could reuse elsewhere; for instance, in a standalone embed viewer. I'll get to that next time.