Page Comparison

...

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).

...

...

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:

Image Removed

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

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:

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:

Image Modified

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:Image Removedthe results shown below.

Image Added

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:

...