Access JumpStart 2.0 | Blog

A Rapid Development Framework for Microsoft Access

Could I do less to check for acceptance of a form object?

So, out of morbid curiosity, I am going to see if I can just create a new Access.Form object again and open it and then pass that to the function. It would be easier for this initial test if I can and the idea behind test driven developments is to incrementally make the tests more and more descriptive of what you are trying to achieve.

In my last session, to get the test to pass, I ended up actually creating a form. Now that I know you have to have the form open to be able to reference it, let’s see if this will work:

Dim NewForm As New Access.Form
NewForm.Open

Well, no, that doesn’t work because a form object doesn’t have an open method. And when you use Docmd.OpenForm, you must use a string as the form’s name which you can’t with a new object like that.

So, I think if I went down the road of programmatically generating the new form and saving it in the database, it would then work. That seems like more code than I wanted to write and I have 2 tests that are passing now, although I do note that my second test is annoyingly long in it’s run time.

Another thing I’ve heard about testing is you want to keep the run times low. We’re going to have a lot of tests, and if every test takes a half second to run, that’s going to make me not want to keep running all the tests all the time.

Probably what I’ll do to mitigate that issue is eventually to create the test form object and open it up early on in the tests and allow multiple tests to run on the same form object. Then I’ll only have the 500ms once instead of every test I want to use on the test form.

Mocks and Fakes?

It’s probably also wise to note here that I’ve heard of “Mocks” and ” Fakes” when doing things like this to speed up testing. Basically you build an object or mimic behavior of an object so that you don’t have to create a live version of the object while running the tests which can be expensive. I’m not exactly sure if either of these things is available to me right now, and I’m just starting, so it’s not a real problem yet. I do know that RubberDuck provides some fakes for VBA, although nothing in terms of an Access Form Fake. I know for example that they provide a MsgBox fake. You can use this in a test to call a “MsgBox” but it doesn’t really present a msgbox to the user because that would defeat the purposes of an automated test. Instead you can verify that the message and buttons you are telling it to display were actually correctly provided when you assert the test conditions.

Next Test

Ok, so on to the next test. I have a few minutes here to see if I can think of what simple thing to test next.

I know that I’m expecting a bound form and that I want to hook into the BeforeUpdate event of that form so that I will be able to start testing against changing form controls. But I’m struggling to come up with a test for that. How would I know that after the setup function is run that it has hooked into the BeforeUpdate event?

I guess I will have to trigger the BeforeUpdate event from the test, but how would I know that the FormListener class is connected? It seems like I will need to write an awful lot of code before a test like that could determine anything. Hmmm… well, I will ponder that and come back tomorrow with more thoughts.