Access JumpStart 2.0 | Blog

A Rapid Development Framework for Microsoft Access

Design for a form auditing object

Ok, so before I can write any tests, I have to think just a little bit about what I want to create so that I can start writing meaningful failing tests that will move me toward where I want this to go. Whew! Sounds kind of confusing, but I don’t think it really is.

Think of this bit as simply defining the “problem”. Where are you at now and where do you want to get to?

Super High level design

I want a class I can instantiate on any bound form, observe the changes the user (or system?) is making and have a list of those changes I can iterate over and output something.

Now start breaking it down (What’s our first test?)

So given the above design (and note how little I actually have there) how can I write a test?

I think my first test should simply be: Instantiate a class.

So I know that will fail because I haven’t written any code yet or even created a database or anything.

Now I’ve got to get to the point where I can actually write a test. So let’s go:

  1. Create a database. How about we create an Access file called FormAuditor.accdb. Easy peasy.
  2. Make sure we install RubberDuckVBA plugin if we haven’t already. So go to the web site and install it:
    Rubberduck VBA web site
  3. Now open the database. My database opened to the Access Object list showing the hidden system objects because of the way I have my Access settings. It didn’t create anything else:
  1. Ok, now I need to open my VBE environment. I usually do this by clicking on CTRL-G.
  1. I’m going to update my settings for Rubberduck to make sure it creates modules with both early binding and late binding coded in and allows us to change it using a compiler constant.
  1. And now I click on my Rubberduck menu choosing Unit Tests -> Test Module which will create a test module
  1. Since I will need to save the test module and it was named TestModule1 by default, I am going to want to give it a more meaningful name. My first class I will call FormListener because I want it to listen for changes, so let’s call the module: TestFormListener. I rename it in the Properties window and then save the database using the disk icon and finally accept the name I just chose as the name of the module to save.
  1. And now I will rename the stub TestMethod1 to create my first failing test, Create_FormListener, and write my first failing bit of code which will live in the “Act” section of the Test Module:
Private Sub CreateFormListener()                        'TODO Rename test
    On Error GoTo TestFail
    Dim FormListenerTest As Object
    Set FormListenerTest = CreateObject("Database.FormListener")

    '@Ignore UnhandledOnErrorResumeNext
    On Error Resume Next
    Exit Sub
    Assert.Fail "Test raised an error: #" & Err.Number & " - " & Err.Description
    Resume TestExit
End Sub