...
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).
...
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. |
...
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:
- Add the TestSupportIncludes global extension (unit testing templates are included in the DCL).
- Go to project properties and set the output type to DLL (that the default for DLL apps is EXE is a long-standing Clarion bug)
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.exe DCL_Clarion_TXAParser_Tests.dll /run
Testing the parser
I made one minor change For information on creating your own test apps see Creating a ClarionTest test DLL.
Testing the parser
In Part 2 I proposed the following test code:
Code Block |
---|
txa DCL_Clarion_TXAParser
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:
...