Back when I first wrote ClarionTest, I only ever used it as a post-build task. That is, I'd build my test DLL and then I'd automatically call ClarionTest and load up my test DLL usually with the /run parameter to run all tests automatically.
Later John Hickey made some nice improvements to ClarionTest, including adding the ability to watch a directory for changes and automatically load the changed test DLL. I never really used that option as the compile-automatically-run-tests-press-ESC-to-get-back-to-my-app cycle worked so well for me.
And then after I adopted the practice of putting my classes in a separate DLL, I found myself doing a whole lot of testing that involved multiple changed DLLs - the class DLL and the unit tests DLL. My old test cycle wasn't so convenient when I was making changes only to the classes.
It was time to revisit John's changes.
An all-source ClarionTest
I was really pleased with the changes John had made to ClarionTest, but at the same time I felt that ClarionTest itself should probably be a better showcase for the idea that important business logic belongs in classes, not in embeds. So I took the radical step of converting ClarionTest from an APP to an all-source project. In the process I stripped out a bunch of generated code that wasn't really needed.
There's still a whole lot of work to be done, however. And that will take time.
For now, my goal is simply to make ClarionTest usable in directory-watching mode. I have a couple of requirements for this:
- Mark (and remember) the test DLL to be run
- Mark (and remember) the individual tests that should be run
- Display a summary of how many tests have failed and how many have passed
- Option to display only the failed tests
- Fix resizing so the last position/size is remembered
Reviewing the code
Diving into the ClarionTest source I noticed an implicit variable right off the bat. It was a simple one - just N#, hard to mess up. But implicits always worry me, and I already had an X variable so I changed all N# to X (after making sure I didn't have any nested loops where I'd already be using X).
I also removed the XML configuration code (because it and the web-style links, replacing them with buttons.
Then I really started hacking away at the code. ClarionTest started out as an ABC app, which is really overkill for something that just shows a window with a few controls and does some pretty basic UI handling. There's all sorts of code there that simply isn't necessary, and again over time I would like ClarionTest itself to be something of a showcase for how you can build up an app using classes.
So I ripped out all of the ABC code.
Next up: some code to read a directory. You know the drill. Declare a queue:
AllFiles QUEUE(File:queue),PRE(FIL) ! END !
Then load up the queue:
Free(AllFiles) DIRECTORY(AllFiles,CLIP(Set:FolderToMonitor) & '\*.DLL',ff_:DIRECTORY)
Simple enough, right? Silly to make that into a class, right?
Nah, turns out I have one on hand already that adds a few bells and whistles. Time to make it part of DCL!
That was easier said than done. My directory class, which also handles things like creating and removing directories, relies on several other classes which had to be brought in to DCL. In their previous ClarionMag incarnation I used some different naming standards and some of the include files had also changed. And then I had a problem with the Clarion CreateDirectory and RemoveDirectory functions, which confused me for a bit as the class has methods by those names also. I do use the Clarion functions as well and it turned out I had to add cwutil.clw to the project so the code would get compiled.
I still have a problem with the directory class - one of the unit tests fails on an attempt to create a directory and then remove it when it isn't empty. But I'll have to leave that for another day. As an aside, one of my goals is to modify ClarionTest so I can execute a set of test DLLs and log the results - that will give me a view of which if any tests are failing throughout the system.
So that was a lot of work just to replace a few lines of code, but it's all part of getting more ClarionMag code into DCL, so it's worth the effort.