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

问题描述

使用同一数据库中的代码，表单和数据我想知道为Microsoft Access应用程序（例如Access 2007）设计一套测试的最佳做法是什么。

测试表单的主要问题之一是只有一些控件有一个 hwnd 句柄和其他控件只获得一个他们有焦点，这使自动化

任何分享的经验？

解决方案

1。写可测试代码

首先，停止将业务逻辑写入您的Form代码。这不是它的地方。它不能在那里正确测试。事实上，你真的不应该测试你的表单本身。它应该是一个死阴影的简单视图，响应用户互动，然后将响应这些操作的责任委派给 可测试的另一个类。

你怎么做的？熟悉，所以这部分我的回答是不公正的，但我会尽量给出一个公平的摘要可用的。

1. AccUnit

   
   
   
   
   
   • 只能在Access中使用。
   
   
   • 需要将测试写为一个奇怪的注释和代码混合体。
   
   
   • 是一个图形界面，可帮助您编写这些奇怪的测试。
   
   
   • 该项目自2013年以来没有任何更新。
   
   



2. VB Lite Unit
   我不能说我亲自使用它，它在那里，但是自2005年以来没有更新。




3. xlUnit
   xlUnit不是可怕的，但它不好，它是笨重，有很多锅炉板代码。这是最糟糕的，但它不工作在Access。

   
   
   

   我拥有在那里，做了那个。这可能比大多数人想要进入，但是完全可能建立一个单位测试框架在本机VBA代码中。




4. Rubberduck VBE加载项的单元测试框架
   
   免责声明：我是合作开发者之一。

   
   
   

   我有偏见，但这是我最喜欢的。

   
   
   
   
   
   
   
   • 更多的文档比你更有效率。
   
   <大多数这些项目。
   
   • 它适用于大多数主要的办公应用程序，而不只是Access。
   
   
   
   

3。开始编写测试

因此，回到第1部分的代码。我们唯一需要测试的代码是 MyModel.Reversed（）函数。所以，让我们来看看这个测试可能是什么样子。 （例子给出使用Rubberduck，但它是一个简单的测试，并可以转换为您选择的框架。）

 '@ TestModule 
 Private Assert As New Rubberduck.AssertClass 
 
'@TestMethod 
 Public Sub ReversedReversesCorrectly（）
 
排列：
 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 
  

撰写好测验指南

2. 良好的测试仅在系统中引入错误或需求发生变化时才会失败。


3. t包括外部依赖关系，如数据库和文件系统。这些外部依赖关系可能导致测试失败，原因超出您的控制范围。其次，他们减慢你的测试。如果您的测试很慢，您就不会运行它们。


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屋！