In my application I have a class object called “ECI_POLineController” with a method called “IsLineValid”.

My job was to be able to write a test for this and I have done that. It needs to set some different values on the line to verify the function returns a correct true/false value depending on the various line field values.

I was able to create a test and instantiate an ECI_POLineController in the test, but the test failed because the IsLineValid function was checking values directly from the line items form object in Access. Since that object wasn’t open in my test and really can’t be opened because there are a lot of things I’d have to do to set it up and open it (like create a dummy db record and allow it to connect to the db and run lots of setup functions) and that would take a long time to run the test.

Instead, I chose to break the form dependency for the IsLineValid function so that I could run the function in a test and use test values there, but when the function ran in the system the same interface would pull in the form values that the function needs. I did this by creating a form reading interface and used two different objects, a test reader and a form reader. IsLineValid will use a function to get the value and the new function uses the new interface.

In the test, I configure the Test reader object, but I set up the new reader function to set the Form reader object if nothing has been initialized yet. In this way, I can specifically set up the test to use the test reader, and the Form will use the Form reader by default. I didn’t have to set up any additional configuration parameters for the system to keep working as it was.

So, my test is almost working, except I found a new dependency in the IsLineValid series of functions. This dependency uses a function in the LineControlManager called LineIsConcrete. So now I have to determine what do do with that dependency.

It turns out LineIsConcrete is hooked directly into the form again. It’s checking more form values directly to determine if the line is a certain type of line.

One thing to consider here is my architecture. It seems silly to have different classes having to all instantiate the same form. I mean it seems silly now as that is a big dependency problem. Also, calling different functions from different modules for determining the state of the line seems like bad architecture to me as well.

I actually have an ECI_PurchaseOrder object which does calculations for the whole PO, and has functions to load everything from an open form or set things on your own. It doesn’t do lines, but it seems like this object might be a better choice overall to add the ability to read the lines. Or a new line object in a similar vein that would abstract the line entirely. Perhaps as a future exercise, I might want to move the whole system toward utilizing a new ECI_PurchaseOrderLine object.

For now, to get this finished and for us to move on, I can add the new form value getting function to the LineControlManager object and set it to use the value I’d like for testing or for live.

Except now my timer went off, so I’ll do all that tomorrow and share the code.