ideas on how to make a test suite

[Phil Freihofner]

I've recently come across the notion (via Agile/Extreme programming) of
test-driven coding, and am trying to apply this to my VBA-Access work. But so
far my attempts have been clumsy failures.

For example, I tried to write a sub (in a class module, and run via <F5>
key) to open a form and "press" the "new patient" button. I can set the focus
on the form's button, no problem, but two attempts at "pressing" it have
failed:

1) SendKeys {"ENTER"} simply moves my cursor around on the coding page, I
can't seem to get it to set the context of my cursor on the form, even with
using setfocus on the button I want to press.
2) The "cmdNewPatient_Click" subroutine (and most of my forms' subroutines)
are PRIVATE, and thus can't be executed from the module and I'd just as soon
leave them that way.
3) I'd rather not spread the tests about on the various form pages, but
rather keep them in their own space and easily removeable prior to generating
the .mde file.

Is there anything to be gained by Automating an instance of Access remotely
and trying to operate it this way? If so, I need to be able to move around on
a form to imitate typical User interactions, and, a way to examine resulting
fields and reports.

Or is this (moving around on a form like a User) something that can be done
via Macros, and have the VBA "testing" module call the macros as needed? I
know a lot of macro commands can be done in VBA using DoCmd, but...it's been
years since I used the Macros directly, and I certainly don't want them being
exposed in the .mde!

Just thought I'd ask as it seems someone must have already figured this out.
I'm guessing if one were in Visual Studio, that would provide a lot more
testing capabilities. (It did from my short experience with it and VB.NET
from a few years ago.)

Many thanks.

 

[Stefan Hoffmann]

hi Phil,

Just thought I'd ask as it seems someone must have already figured this out.
I'm guessing if one were in Visual Studio, that would provide a lot more
testing capabilities. (It did from my short experience with it and VB.NET
from a few years ago.)

http://old.nabble.com/how-would-you-tdd-VBA--td7680532.html

and use SoC. So you can test your logic.

For testing the GUI, I think you have to do some Win32 API programming like

http://support.microsoft.com/kb/183009

to find the controls window handle. And then use SendMessage to send a
mouse click to it.
A problem may occur due to the way Access creates controls on the form.
So not necessarily ever control has a window handle.


mfG
--> stefan <--

 

[Phil Freihofner]

Thanks for the leads, but they aren't working. There are a couple suggestions
in the old.nabble... link that are useful, sort of. For the sake of other
people that might find this question, I'll list some of my travails here.

I'm just trying to do a very simple GUI case at this point: automate the
pressing of button on a form.

1) Write test code on the module you are testing, and make a Public sub that
executes the tests, and make a sub that calls all the Public test subs, to
run the entire "test suite". This works, but does not test the GUI, and
significantly expands the amount of code you are packing in the app.

(Now if this were Java-based, one could extend the class to a testClass and
be able to invoke the Private subs on the parent class. This is how JUnit is
set up, typically. But I haven't done GUI tests on Java yet, either, I have
to admit.)

2) In a sub, use a DoCmd.OpenForm "Foo", then call the
Form_Foo.cmdButton_Click sub. But this will only work if the cmdButton_Click
sub is Public.

Using MACROS & Automation
3) Make a macro "PressIt" with the single command: SendKeys ~. Now, if you
execute this directly, it will repeatedly <Enter> itself, running in an
endless loop. So, it must be run from the context of the open form. So, in
the module, open the form "Foo" and put the focus on the button, and call
DoCmd.RunMacro "PressIt". Unfortunately, computer will hang. (I did some
debug.print screen.activecontrol.name commands and the focus never left the
button I was trying to press, for whatever that is worth.)

3a) Doing 3 via automation (e.g., from a second access program) also causes
the program to hang.

3b) Adding a couple lines to the macro, using it to open the form and set
the focus was fine (both locally and via automation), but the sendkeys ~
never worked. (I should mention, I also tried {ENTER} which is also a way to
designate the return key.

4) Write a macro and have it call the module's cmdButton_Click function? No
can do. The functions that can be executed from a macro are limited to those
that come up with the simple function editor.

5) Use automation and SendKeys? I could find no way to make the SendKeys use
the target as the execution environment. This includes using Shell and
AppActivate. In these experiments, the base Access program opens, but I
couldn't find a way to even send a down-arrow command (usually {DOWN} works
fine) that would interact with the target app.

So, MS Access seems to be a..."poor choice" if you want to do any automated
testing or TDD. Maybe this will change at some point, but for now, I'm
thinking maybe my database app has outgrown it's host app and I should look
at migrating it.

Any suggestions as to databases that support TDD on their GUIs?

Thanks.

 

[Stefan Hoffmann]

hi Phil,

thanks for posting your findings.

So, MS Access seems to be a..."poor choice" if you want to do any automated
testing or TDD. Maybe this will change at some point, but for now, I'm
thinking maybe my database app has outgrown it's host app and I should look
at migrating it.

Access is a great RAD tool. Like others, TDD isn't a design goal.

And to be honest: RAD and TDD are two kind of approaches of software
development which are not necessarily conflicting, but to some extend
distinct from each other.

Any suggestions as to databases that support TDD on their GUIs?

You use an external tool like AutoIt:

http://stackoverflow.com/questions/120359/tools-for-automated-gui-testing-on-windows


mfG
--> stefan <--