Ok, so now why am I creating all these objects in my test? How about creating the objects I want to see returned and use those to run the test on the form and then see if it’s the same objects I get back?
I kinda feel like that is making the tests brittle because I’m utilizing implementation. BUT…. These are potentially user facing objects they’ll be getting back and manipulating while running the logger.
Therefore, I’m going to try it. So the test looks like this now:
I think I want to build an AuditFieldChange object for each change… like this:
Crap, hold it. That won’t work. The AuditFieldChange only has an “OldValue” and “NewValue” property. But maybe I could build the expected AuditEventsDetails object with the FieldChanges…. Bah, no, cause I’m going to start adding stuff to the objects and then old tests will fail until I add all those elements. Hmmph… back to the drawing board I think.
I guess what I could do is use those arrays containing the field names and values and create a function to make the changes, create the… ugh. Why am I doing this? the code is ugly, but I may not do much more testing. Probably just for different Access field types. Ok, yeah that makes sense to me. I will create a function that will need to take the field names, old values, and new values for each field. I’ll start with that.
I’m running out of time, but here’s my function so far. I’m currently in a very broken state. Perhaps I shouldn’t have tried to bite off so much to refactor at once, but I think it is moving in the right direction. We’ll keep moving forward tomorrow.