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.
...
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:A while back I took the radical step of converting ClarionTest from an APP file to an all-source project. I wasn't entirely sure at the time why I was doing it. In part it was a wild impulse to get my hands on the source code in a way not possible as long as it remained in an APP.
But as I thought about this, I realized that ClarionTest really does belong as source code. It exists because I was fed up with having my business logic buried in embed points, and not only did I want to move that logic into reusable classes I also wanted to be able to test that business logic in some automated way.
There were some odd contradictions in the first versions of ClarionTest. I realized that most of the business logic in ClarionTest itself was embed code. Perhaps that was an inevitable bit of bootstrapping, but once I had ClarionTest it made sense to move the app's own logic to ClarionTest, test it with ClarionTest, and then replace the ClarionTest embed code with the classes.'
Did that make any sense?
The more classes I write, and the more I learn about how I can write classes (there is always more to learn), the less satisfied I am with how the ABC class library (the foundation for the ABC templates) does things. That doesn't mean ABC is terrible code - it does lots of things well. But it's a pretty old design, and it does have some code smell.
So why not make ClarionTest a showcase for all the things that are potentially great about Clarion object oriented programming, separation of concerns, and all those other technologies, techniques and practices that make for better software?
Given that premise, I ripped almost everything out of the ClarionTest source except for the window definitions and the data declarations necessary to compile those windows. And I started over.
Starting over (again and again)
Don't for a minute think that whatever I'm describing in the following text is the "final" version of ClarionTest. If anything, ClarionTest has been, is and will be in a state of evolution. There are compromises and failures in the current code. When I notice them I'll comment on them, and try give some reason for my choices. And I'll come back to the code periodically and complain about the crap I wrote last time. To paraphrase Anil Dash, writing code is all about trying to suck less. That doesn't mean I'm not ever happy with my code - I frequently sit back and look at something I've written with a great deal of satisfaction. But I know that just because it looks good now doesn't mean it will look equally good down the road.
- 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
...