测试 MS Access 应用程序的最佳方式? [英] Best way to test a MS Access application?

问题描述

使用同一数据库中的代码、表单和数据，我想知道为 Microsoft Access 应用程序(例如 Access 2007)设计一套测试的最佳实践是什么.

测试表单的主要问题之一是只有少数控件具有 hwnd 句柄，而其他控件仅获得一个它们具有焦点的控件，这使得自动化非常不透明，因为您无法获得控制要执行的表单.

有什么经验可以分享吗?

解决方案

1.编写可测试的代码

首先，停止将业务逻辑写入表单背后的代码中.那不是它的地方.在那里无法正确测试.事实上，您根本不需要测试表单本身.它应该是一个非常愚蠢的简单视图，它响应用户交互，然后将响应这些操作的责任委托给另一个可测试的类.

你是怎么做到的?熟悉，所以我的这部分答案并不公正，但我会尽量对可用的内容进行公正的总结.

1. AccUnit

   • 仅适用于 Access.
   • 要求您将测试编写为注释和代码的奇怪混合体.(评论部分没有智能感知.
   • 是一个图形界面，可以帮助您编写那些看起来很奇怪的测试.
   • 该项目自 2013 年以来没有任何更新.

2. VB Lite 单元我不能说我个人使用过它.它就在那里，但自 2005 年以来一直没有更新.

3. xlUnitxlUnit 并不糟糕，但也不好.它很笨重，而且有很多样板代码.这是最好的，但它在 Access 中不起作用.所以，就这样了.

4. 构建自己的框架

   我去过那里并做到了.这可能比大多数人想要的要多，但完全有可能用原生 VBA 代码构建单元测试框架.

5. Rubberduck VBE 插件的单元测试框架
   免责声明:我是共同开发者之一.

   我有偏见，但这是迄今为止我最喜欢的.

   • 几乎没有样板代码.
   • 智能感知可用.
   • 该项目处于活动状态.
   • 比大多数这些项目更多的文档.
   • 它适用于大多数主要办公应用程序，而不仅仅是 Access.
   • 不幸的是，它是一个 COM 加载项，因此必须将其安装到您的计算机上.

3.开始编写测试

所以，回到我们在第 1 部分中的代码.我们真正需要测试的唯一代码是 MyModel.Reversed() 函数.那么，让我们来看看这个测试会是什么样子.(给出的示例使用 Rubberduck，但它是一个简单的测试，可以转换为您选择的框架.)

'@TestModule私有断言作为新的 Rubberduck.AssertClass'@测试方法公共子 ReversedReversesCorrectly()安排:将模型调暗为新 MyModelConst original As String = "Hello"预期常量为字符串 = "olleH"Dim 实际作为字符串模型.文本 = 原始行为:实际 = 模型.反转断言:Assert.AreEqual 预期，实际结束子

编写好的测试指南

1. 一次只测试一件事.
2. 只有在系统中引入错误或需求发生变化时，良好的测试才会失败.
3. 不要包含外部依赖项，例如数据库和文件系统.这些外部依赖项可能会导致测试因您无法控制的原因而失败.其次，它们会减慢您的测试速度.如果你的测试很慢，你就不会运行它们.
4. 使用描述测试内容的测试名称.如果时间长了也不要担心.最重要的是它是描述性的.

<小时>

我知道这个答案有点长而且有点晚，但希望它可以帮助一些人开始为他们的 VBA 代码编写单元测试.

With the code, forms and data inside the same database I am wondering what are the best practices to design a suite of tests for a Microsoft Access application (say for Access 2007).

One of the main issues with testing forms is that only a few controls have a hwnd handle and other controls only get one they have focus, which makes automation quite opaque since you cant get a list of controls on a form to act on.

Any experience to share?

解决方案

1. Write Testable Code

First, stop writing business logic into your Form's code behind. That's not the place for it. It can't be properly tested there. In fact, you really shouldn't have to test your form itself at all. It should be a dead dumb simple view that responds to User Interaction and then delegates responsibility for responding to those actions to another class that is testable.

How do you do that? Familiarizing yourself with the Model-View-Controller pattern is a good start.

It can't be done perfectly in VBA due to the fact that we get either events or interfaces, never both, but you can get pretty close. Consider this simple form that has a text box and a button.

In the form's code behind, we'll wrap the TextBox's value in a public property and re-raise any events we're interested in.

Public Event OnSayHello()
Public Event AfterTextUpdate()

Public Property Let Text(value As String)
    Me.TextBox1.value = value
End Property

Public Property Get Text() As String
    Text = Me.TextBox1.value
End Property

Private Sub SayHello_Click()
    RaiseEvent OnSayHello
End Sub

Private Sub TextBox1_AfterUpdate()
    RaiseEvent AfterTextUpdate
End Sub

Now we need a model to work with. Here I've created a new class module named MyModel. Here lies the code we'll put under test. Note that it naturally shares a similar structure as our view.

Private mText As String
Public Property Let Text(value As String)
    mText = value
End Property

Public Property Get Text() As String
    Text = mText
End Property

Public Function Reversed() As String
    Dim result As String
    Dim length As Long

    length = Len(mText)

    Dim i As Long
    For i = 0 To length - 1
        result = result + Mid(mText, (length - i), 1)
    Next i

    Reversed = result
End Function

Public Sub SayHello()
    MsgBox Reversed()
End Sub

Finally, our controller wires it all together. The controller listens for form events and communicates changes to the model and triggers the model's routines.

Private WithEvents view As Form_Form1
Private model As MyModel

Public Sub Run()
    Set model = New MyModel
    Set view = New Form_Form1
    view.Visible = True
End Sub

Private Sub view_AfterTextUpdate()
    model.Text = view.Text
End Sub

Private Sub view_OnSayHello()
    model.SayHello
    view.Text = model.Reversed()
End Sub

Now this code can be run from any other module. For the purposes of this example, I've used a standard module. I highly encourage you to build this yourself using the code I've provided and see it function.

Private controller As FormController

Public Sub Run()
    Set controller = New FormController
    controller.Run
End Sub

---

So, that's great and all but what does it have to do with testing?! Friend, it has everything to do with testing. What we've done is make our code testable. In the example I've provided, there is no reason what-so-ever to even try to test the GUI. The only thing we really need to test is the model. That's where all of the real logic is.

So, on to step two.

2. Choose a Unit Testing Framework

There aren't a lot of options here. Most frameworks require installing COM Add-ins, lots of boiler plate, weird syntax, writing tests as comments, etc. That's why I got involved in building one myself, so this part of my answer isn't impartial, but I'll try to give a fair summary of what's available.

1. AccUnit

   • Works only in Access.
   • Requires you to write tests as a strange hybrid of comments and code. (no intellisense for the comment part.
   • There is a graphical interface to help you write those strange looking tests though.
   • The project has not seen any updates since 2013.

2. VB Lite Unit I can't say I've personally used it. It's out there, but hasn't seen an update since 2005.

3. xlUnit xlUnit isn't awful, but it's not good either. It's clunky and there's lots of boiler plate code. It's the best of the worst, but it doesn't work in Access. So, that's out.

4. Build your own framework

   I've been there and done that. It's probably more than most people want to get into, but it is completely possible to build a Unit Testing framework in Native VBA code.

5. Rubberduck VBE Add-In's Unit Testing Framework
   Disclaimer: I'm one of the co-devs.

   I'm biased, but this is by far my favorite of the bunch.

   • Little to no boiler plate code.
   • Intellisense is available.
   • The project is active.
   • More documentation than most of these projects.
   • It works in most of the major office applications, not just Access.
   • It is, unfortunately, a COM Add-In, so it has to be installed onto your machine.

3. Start writing tests

So, back to our code from section 1. The only code that we really needed to test was the MyModel.Reversed() function. So, let's take a look at what that test could look like. (Example given uses Rubberduck, but it's a simple test and could translate into the framework of your choice.)

'@TestModule
Private Assert As New Rubberduck.AssertClass

'@TestMethod
Public Sub ReversedReversesCorrectly()

Arrange:
    Dim model As New MyModel
    Const original As String = "Hello"
    Const expected As String = "olleH"
    Dim actual As String

    model.Text = original

Act:
    actual = model.Reversed

Assert:
    Assert.AreEqual expected, actual

End Sub

Guidelines for Writing Good Tests

1. Only test one thing at a time.
2. Good tests only fail when there is a bug introduced into the system or the requirements have changed.
3. Don't include external dependencies such as databases and file systems. These external dependencies can make tests fail for reasons outside of your control. Secondly, they slow your tests down. If your tests are slow, you won't run them.
4. Use test names that describe what the test is testing. Don't worry if it gets long. It's most important that it is descriptive.

---

I know that answer was a little long, and late, but hopefully it helps some people get started in writing unit tests for their VBA code.

这篇关于测试 MS Access 应用程序的最佳方式?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！