by
...
Unknown user
In Part 2 of this series I extracted my TXA parsing code into a class for easier reuse.
Perhaps What I find more interesting to me than simple reuse is that by moving my code into a class I've made it testable. But what does testing really mean , in the Clarion world? Usually it means writing some code in an embed point, running the app, clicking some clicks interacting like a user would (theoretically) and watching what happens. That's useful, but it doesn't necessarily tell you what you need to know about the reliability of your core code. And it's tedious.
You can take away some of the tedium with automated UI testing tools, except that historically Clarion hasn't played well with those tools because Clarion apps make use custom Windows controls.
Perhaps UI testing is easier now - I haven't look at this area in years. If you have current information please post a comment below. But even if you can use your apps reliably with UI testing tools, you still won't be testing your app's core functionality in an optimal way.
Testing is a complex subject, and there are lots of different ways to test application code, but certainly one of the most useful is unit testing. The core idea is that you reduce your code to the smallest testable units, and then you run tests on a regular basis. Those tests must be automated; they have to run without user intervention (other than to kick off a series of tests, although you might want a test suite to run automatically on a regular basis, or as part of a build).
...
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.
| Info |
|---|
ClarionTest is included in the freely available DevRoadmaps Clarion Library, as is the TXA parser code. |
...
| Tip |
|---|
I can't emphasize enough how important a good naming convention is for managing Clarion class libraries. All too often I see classes buried in files with cryptic 8.3 filenames. We've had long filenames since Windows '95, people. I also strongly recommend sticking with one class per INC/CLW file pair and using the same name for the class as for the file. |
Creating the test app (DLL)
When I create unit test apps I remove the First Procedure name and set the Destination Type to DLL. I also uncheck the Application Wizard:
I've included DCL_Clarion_TXAParser_Tests.app in the DevRoadmaps Clarion Library on GitHub.
There are two essential steps to configuring any new unit test app:
...
For information on creating your own test apps see Creating a ClarionTest test DLL (DCL).
...
I also like to automatically run my unit tests, and to make that easy I always create my unit tests inside the DCL directory tree, under the UnitTests folder. I then update my post-build task to look like this:
..\ClarionTest.exe appname.dll /run
So in this case the post-build task is:
..\ClarionTest.exeTesting the parser
In Part 2 I proposed the following test code:
| Code Block |
|---|
txa DCL_Clarion_TXAParser |
...
Testing the parser
...
code
txa.Parse('test.txa')
AssertThat(txa.GetEmbedCount(),IsEqualTo(6),'Wrong number of embeds found in TXA') |
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.
...
When I build the app I get an automatic execution of the above tests (thanks to the post-build task), like this:the results shown below.
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.