by Unlicensed user
In Part 2 of this series I extracted my TXA parsing code into a class for easier reuse.
Perhaps 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 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.
...
I made one minor change in my test code, adding a second check for the number of procedures:
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:
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:
...