Webinar this Friday: If you can't test your code, how do you know it isn't crap?
Posted February 8 2011
Most Clarion developers use Clarion because of the AppGen; they let it do the grunt work, and they slot their own code into various embed points.
But it's possible to overuse embeds. Put all your source code there and you can't really reuse it, short of copying and pasting.
So what's the answer?
The first step is to start pulling that embed code out into reusable procedures or, even better, classes.
But that's just the first step.
The next, and absolutely vital, step is to create automated tests you can execute against that code.
Most of us don't really test our code. We write some embed code, and then we run the app and we click some buttons and type some text and check to see if everything's running as expected. Or worse, we let our customers do the testing.
That's little more than throwing code up against the wall to see what sticks. It's not systematic, it's not easily repeatable, and above all it isn't automated.
If you want your applications to be competitive, they have to be reliable. And the first step to ensuring the reliability of your entire application is to begin verifying the reliability of the code you write.
The webinar
On Friday, February 11 2011 join me in a ClarionLive webinar on unit testing. During the webinar I will take the ClarionLive Class Bash ASCII file reading/writing classes and submit them to unit testing, using the ClarionTest framework. I'll show how to write tests for the existing classes and I'll explore a number of refactorings to make those classes more testable and reusable.
The webinar starts at 9 a.m. PST (GMT-8). Please register ahead of time.
Article comments
Search ClarionMag
From the archives
Making Sense of ABC's ErrorClass - Part 1
11/21/2000 12:00:00 PM
If there's one part of ABC that consistently draws fire, it's ErrorClass. In this three part series, Russ Eggen puts on his flak jacket and steps out into no man's land to explain what ErrorClass is all about, why it's good, and what you can do with it.
by Andrew Barnham on February 8 2011 (comment link)
Shame I am in such an ungodly timezone. Will watch once vid is online.
Clarion language syntactically has a powerful advantage for providing supporting tools for a comprehensive test framework: the ACCEPT loop and a restricted number of GUI widgets. On my TODO list, I will hopefully have lots of free time in a month or two, is to hook a test framework into Clarion2Java. The runtime/compiler itself has a test suite of over 2000+ test cases; but not framework yet to write tests for clarion code itself; and having done unit testing for years now I am very eager to throw some test code around the apps I look after.
Automated testing of GUI apps, even webapps to some extent, is painful. Simulating KB and mouse gestures is highly brittle process (as evidenced in test cases in clarion2java runtime). But with ACCEPT loop you only need to record event list + a little bit of logic to track implied behaviour/state of some of the controls. i.e. ACCEPT on entry control changes value of the variable the ENTRY USE() wraps. The beauty of it is that on your test runner playback you don't need to startup an actual GUI environment. You could have a test running ACCEPT loop that is GUI-less and whose primary purpose is to test behaviour/logic of the application. The test obviously doesn't provide 100% coverage, but the resulting test code will be simple and easy to manage, non-brittle and exercises the truly important bits: a good trade off in my mind.
Also the work effort should not be substantial; a few weeks only. Part of that would involve writing a recorder; like recorder in Selenium. The recorder will monitor your app as you manually use it, automatically write the clarion (or java) test code and you only need tweak it to iron out non obvious bits, such test conditions that may change: like todays date etc.
by David Harms on February 8 2011 (comment link)
Andrew,
Those are some very interesting suggestions.
I won't actualy be dealing with the GUI at all - I'll be focusing on testing the business logic. I'll also be touching on some of the differences between test-first and test-after development.
Dave