Many-to-many checkboxes revisited, part 8: The persister class unit test

Owned by David Harms
Last updated: Nov 28, 2014Version comment
9 min read

by Unknown user

In the previous installment I wrote a successful unit test that saved and loaded checkbox data. By way of refresher, here's that code:

SaveAndLoadData PROCEDURE  (*long addr)              ! Declare Procedure
 
 
ManytoMany                  CML_Data_ManyToManyLinks 
                            itemize(),pre()
RightRecordX                    equate
RightRecordY                    equate
RightRecordZ                    equate
                            end
Persister                   CML_Data_ManyToManyLinksPersisterForTPS
Filename                    cstring(500)
 
    CODE
    addr = address(UnitTestResult)
    BeginUnitTest('SaveAndLoadData')
     
    Persister.SetFilename(Filename)
    ManytoMany.Persister &= Persister
    ManyToMany.LeftRecordID = 1
     
    ManyToMany.SetLinkTo(RightRecordX)
    ManyToMany.SetLinkTo(RightRecordZ)
    AssertThat(ManyToMany.IsLinkedTo(RightRecordX),IsEqualTo(true), 'before save, record X should be linked')
    AssertThat(ManyToMany.IsLinkedTo(RightRecordY),IsEqualTo(false),'before save, record Y should not be linked')
    AssertThat(ManyToMany.IsLinkedTo(RightRecordZ),IsEqualTo(true), 'before save, record Z should be linked')
     
    ManyToMany.Save()
    ManyToMany.Reset()
    AssertThat(ManyToMany.IsLinkedTo(RightRecordX),IsEqualTo(false),'after reset, record X should not be linked')
    AssertThat(ManyToMany.IsLinkedTo(RightRecordY),IsEqualTo(false),'after reset, record Y should not be linked')
    AssertThat(ManyToMany.IsLinkedTo(RightRecordZ),IsEqualTo(false),'after reset, record Z should not be linked')
     
    ManytoMany.Load()
     
    AssertThat(ManyToMany.IsLinkedTo(RightRecordX),IsEqualTo(true), 'after load, record X should be linked')
    AssertThat(ManyToMany.IsLinkedTo(RightRecordY),IsEqualTo(false),'after load, record Y should not be linked')
    AssertThat(ManyToMany.IsLinkedTo(RightRecordZ),IsEqualTo(true), 'after load, record Z should be linked')

You can ignore the first two lines of code as they're standard setup for the unit test procedure, and required by ClarionTest. 

First I assign the Persister object to the ManyToMany object. 

Then I set some links to the right-side records and verify that the ManyToMany object correctly maintains those links. 

I call ManyToMany.Save(), which as you'll recall from last time checks to see if there's a Persister object, and if there is one it calls that object's Save method. 

I then call ManyToMany.Reset() and verify that all the previous associations have been wiped out, so I can be sure that anything I test after a Load() is there because of Load(). 

And finally I Load() the saved values and verify that ManyToMany now has the expected state.

Now let's take a closer look at this line of code:

ManytoMany.Persister &= Persister

In the ManyToMany class, the Persister property is declared like this:

Persister &CML_Data_ManyToManyLinksPersister

But in my code above, the Persister object isn't of type CML_Data_ManyToManyLinksPersister, it's of type CML_Data_ManyToManyLinksPersisterForTPS. How is it possible to declare a reference variable of one type and then pass it an object of another type? 

The answer is in the declaration for CML_Data_ManyToManyLinksPersisterForTPS:

CML_Data_ManyToManyLinksPersisterForTPS         Class(CML_Data_ManyToManyLinksPersister),Type,Module('CML_Data_ManyToManyLinksPersisterForTPS.CLW'),Link('CML_Data_ManyToManyLinksPersisterForTPS.CLW',_CML_Classes_LinkMode_),Dll(_CML_Classes_DllMode_)
Filename                                            cstring(500),protected
Construct                                           Procedure()
Destruct                                            Procedure()
Load                                                procedure(long leftRecordID,CML_Data_ManyToManyLinksData linksData),derived
Save                                                procedure(long leftRecordID,CML_Data_ManyToManyLinksData linksData),derived
SetFilename                                         procedure(string filename)
                                                End

The Class declaration

Class(CML_Data_ManyToManyLinksPersister)

means that CML_Data_ManyToManyLinksPersisterForTPS is derived from CML_Data_ManyToManyLinksPersister, so for all intents and purposes the ManyToMany instance sees the Persister object as an instance of CML_Data_ManyToManyLinksPersister. In fact, when the ManyToMany instance calls the Save() method, it "thinks" (if you'll forgive the anthropomorphism) that it's calling Save() on an instance of CML_Data_ManyToManyLinksPersister. 

But in CML_Data_ManyToManyLinksPersister the Save method is just a stub:

 

CML_Data_ManyToManyLinksPersister.Save          procedure(long leftRecordID,CML_Data_ManyToManyLinksData linksData)
    code

The code I really want to execute is in the CML_Data_ManyToManyLinksPersisterForTPS class:

CML_Data_ManyToManyLinksPersisterForTPS.Save    procedure(long leftRecordID,CML_Data_ManyToManyLinksData linksData)
x                                                   long
    code
    dbg.write('CML_Data_ManyToManyLinksPersisterForTPS.Save')
    ! Warning - the following code, although workable, is highly inefficient and will be rewritten
    if self.OpenDataFile()
        ! Clear out any existing 
        clear(Links:Record)
        Links:LeftRecordID = LeftRecordID
        set(Links:kLeftRight,Links:kLeftRight)
        loop
            next(LinksDataFile)
            if errorcode() or Links:LeftRecordID <> LeftRecordID then break.
            dbg.write('deleting existing LinksDataFile record with Links:LeftRecordID ' & Links:LeftRecordID & ', Links:RightRecordID ' & Links:RightRecordID & ': ' & error())
            delete(LinksDataFile)
        end
        dbg.write('records(LinksData.LinksQ) ' & records(LinksData.LinksQ))
        loop x = 1 to records(LinksData.LinksQ)
            get(LinksData.LinksQ,x)
            clear(Links:Record)
            Links:LeftRecordID = LinksData.LinksQ.LeftRecordID
            Links:RightRecordID = LinksData.LinksQ.rightRecordID
            dbg.write('adding LinksDataFile record with Links:LeftRecordID ' & Links:LeftRecordID & ', Links:RightRecordID ' & Links:RightRecordID & ': ' & error())
            add(LinksDataFile)
            if errorcode() 
                dbg.write('Error adding record: ' & error())
            else
                dbg.write('Success adding record')
            end
        end
        self.CloseDataFile()
    end

Ordinarily, the only way I could get this code to execute would be to change the reference in CML_Data_ManyToManyLinks from

Persister                                           &CML_Data_ManyToManyLinksPersister

to

Persister                                           &CML_Data_ManyToManyLinksPersisterForTPS

That would work but it would have the very undesirable side effect of hard wiring in my TPS persister. If I decided that in one part of my application I wanted a TPS persister and in another I wanted, say, an XML persister, I'd have to make a full copy of my CML_Data_ManyToManyLinks class and adapt it for the XML persister. 

Wouldn't it be nice if there was a way to keep the generic reference to  CML_Data_ManyToManyLinksPersister yet be able to call the code in any derived class?

Happily there is exactly such a mechanism, and it is called the virtual method. 

Virtual methods

The Save and Load methods in CML_Data_ManyToManyLinksPersister both have a ,virtual attribute:

Load                                                procedure(long leftRecordID,CML_Data_ManyToManyLinksData linksData),virtual
Save                                                procedure(long leftRecordID,CML_Data_ManyToManyLinksData linksData),virtual

When the virtual attribute is present on any method in the class the compiler creates something called a virtual method table (VMT) for that class. 

If a derived class has a method with the same name and prototype as a virtual method in the parent class, and that method has the virtual attribute, then any time the parent method is called the runtime library consults the VMT to see if there is a derived method that should be called instead. 

Virtual methods are one of the most powerful and compelling features of object-oriented programming. They allow you to selectively replace code in a parent class with your own code. Among other things, they are the mechanism by which most embed code is inserted into ABC applications. 

Derived virtual methods

To guarantee that your virtual methods are called in place of the parent class methods they must have the same name and prototype as the parent class methods. It's easy to make a mistake in a derived class and have a subtly different method signature. This could be the result of a typo, or because you made a change to the parent method and forgot to change the derived class method. What you end up with then is a derived virtual method that isn't derived at all; instead it's a new "top level" method that just happens to have a virtual attribute, but which will never get called in place of the method in the parent class. 

To avoid this problem always use 

,derived

rather than

,virtual

when declaring virtual methods in the derived classes. That tells the compiler that it must find a matching virtual method in the parent class. If there's a mismatch you'll get a "DERIVED procedure does not match parent prototype" error and you'll know something needs fixing. 

Virtual methods are so incredibly useful that some developers argue that all methods should be virtual by default. In Java, for instance, this is true of all non-static methods. In C# (as in Clarion) you have to explicitly declare methods as virtual. 

A blunt instrument

The Save method as written is something of a blunt instrument; it simply wipes out any existing data then adds in the new data. It will come in for some refinement a little later in the process.

The Load method is a simple bit of code that loads values from the file into the data queue. 

Wiring the unit-testable class into the UI example program

Unit testing can be incredibly useful, but sometimes wiring unit-tested code into a working program reveals new issues that need to be addressed. I'll cover those next time.

 

 

Â