Back to getting a failing test. I am wanting to make sure that the user can configure any particular form to use this FormAuditor class easily, so I want my next tests to indicate that. Here are a few scenarios I already had on my test list:

• Easily load the form auditor object into a form.
• Test whether this is a bound form.

So an error condition of some kind for unbound forms and the ability to easily load the form auditor object into a form.

I can think of a few other error conditions we might run into as well like:

• Alert user if form does not exist
• Alert user if form is not open (this will cause failure to get an instance of the form)
• Alert user if the form auditor is overwiting a macro or code written directly in the BeforeUpdate property.

I want to focus on the very first one mentioned before we get into edge cases. I’m thinking there might be a couple of ways I want to handle the Form Auditing as a user of the class. One would be to create and track a form right from the code behind that form. Perhaps a one liner of some sort in the Form Open event. In any event there will need to be a way to set the form for the user and run the initialization code on that form.

I also am thinking the user may want to create an auditor object by itself and assign a form to it, or maybe even multiple forms. Some sort of main navigation form that would track the usage of various form objects. Although, they could easily create multiple Form Auditor objects, one for each class. So that will prevent us from having to manage multiple forms in our class.

Let’s start simple. We need to be able to pass the desired form object to the Form Auditor to initialize it. So I’ll start there. Let’s call the method SetFormToAudit and pass it a Form for auditing.

I’m creating a new RubberDuck Test module via the RubberDuck Insert Test Module command on the menu in the VB IDE. I’ve called the module “TestGivenFormAuditorInit” and will add the first test next time.