Having dealt with most of the messy UI code, I'm ready for some clean, efficient, highly rational business logic. This is work I usually do in unit tests. And the first thing I need is a unit test app, one that will run with my ClarionTest unit testing framework.
I begin by creating a new unit test app from a TXA that comes with ClarionTest.
By convention I usually create a unit test app for each class, and I give the app the same name as the class with a "Tests" suffix. I know my class prefix will be CML_ (for ClarionMagLibrary). But I haven't got a class name yet.
Which leaves me stumped again:
It's hard because the whole time I'm thinking about class design I'm trying to keep the class as generic as possible. A class that handles just one situation is a last resort. Also while I'll be using this class in conjunction with a UI class, it doesn't have anything to do with the UI. But it does have to do with data, and it does have to do with managing many-to-many relationships. So provisionally I've decided to call the class CML_Data_ManyToManyLinks and the app CML_Data_ManyToManyLinksTests.
I create the class using John Hickey's excellent ClarionLive! Class Creator, part of the ClarionLive! Utilities:
I've defined my baseline class that uses the CML conventions. It's included in CML as CML_BaseClass.inc and CML_BaseClass.clw.
The TXA created a sample unit test procedure for me. But what will my first unit test be?
The first unit test
At the risk of repeating myself even more than usual, one of the things I like best about test-driven development is it forces me to think about how I want to use my classes long before I think about how to write them. And that's almost always a more productive approach.