Der beste Weg, eine MS Access-Anwendung zu testen?

StackOverflow https://stackoverflow.com/questions/47400

Frage

Da sich Code, Formulare und Daten in derselben Datenbank befinden, frage ich mich, welche Best Practices zum Entwerfen einer Testreihe für eine Microsoft Access-Anwendung (z. B. für Access 2007) geeignet sind.

Eines der Hauptprobleme beim Testen von Formularen besteht darin, dass nur wenige Steuerelemente über eine verfügen hwnd handle und andere Steuerelemente erhalten nur eines, auf das sie den Fokus haben, was die Automatisierung ziemlich undurchsichtig macht, da Sie in einem Formular keine Liste von Steuerelementen erhalten können, auf die Sie reagieren können.

Gibt es Erfahrungen, die Sie teilen können?

War es hilfreich?

Lösung

1.Schreiben Sie testbaren Code

Hören Sie zunächst auf, Geschäftslogik in den Code dahinter Ihres Formulars zu schreiben.Das ist nicht der richtige Ort dafür.Es kann dort nicht richtig getestet werden.Tatsächlich sollten Sie Ihr Formular selbst überhaupt nicht testen müssen.Es sollte eine völlig dumme, einfache Ansicht sein, die auf Benutzerinteraktionen reagiert und dann die Verantwortung für die Reaktion auf diese Aktionen an eine andere Klasse delegiert Ist testbar.

Wie machst du das?Machen Sie sich mit dem vertraut Model-View-Controller-Muster ist ein guter Anfang.

Model View Controller diagram

Das geht nicht perfekt in VBA aufgrund der Tatsache, dass wir entweder Ereignisse oder Schnittstellen erhalten, niemals beides, aber Sie können dem ziemlich nahe kommen.Betrachten Sie dieses einfache Formular mit einem Textfeld und einer Schaltfläche.

simple form with text box and button

Im dahinterliegenden Code des Formulars verpacken wir den Wert der TextBox in eine öffentliche Eigenschaft und lösen alle Ereignisse, die uns interessieren, erneut aus.

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

Jetzt brauchen wir ein Modell, mit dem wir arbeiten können.Hier habe ich ein neues Klassenmodul mit dem Namen erstellt MyModel.Hier liegt der Code, den wir testen werden.Beachten Sie, dass es natürlich eine ähnliche Struktur wie unsere Ansicht aufweist.

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

Schließlich verkabelt unser Controller alles miteinander.Der Controller wartet auf Formularereignisse, übermittelt Änderungen an das Modell und löst die Routinen des Modells aus.

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

Jetzt kann dieser Code von jedem anderen Modul ausgeführt werden.Für dieses Beispiel habe ich ein Standardmodul verwendet.Ich empfehle Ihnen dringend, dies selbst mit dem von mir bereitgestellten Code zu erstellen und zu sehen, wie es funktioniert.

Private controller As FormController

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

Also, das ist großartig und so aber was hat das mit testen zu tun?! Freund, das hat es alles mit dem Testen zu tun.Wir haben unseren Code erstellt testbar.In dem von mir bereitgestellten Beispiel gibt es überhaupt keinen Grund, überhaupt zu versuchen, die GUI zu testen.Das Einzige, was wir wirklich testen müssen, ist das model.Darin liegt die wahre Logik.

Also weiter zu Schritt zwei.

2.Wählen Sie ein Unit-Testing-Framework

Hier gibt es nicht viele Möglichkeiten.Die meisten Frameworks erfordern die Installation von COM-Add-Ins, viel Standardarbeit, seltsame Syntax, das Schreiben von Tests als Kommentare usw.Deshalb habe ich mich engagiert Ich baue selbst eins, Daher ist dieser Teil meiner Antwort nicht unparteiisch, aber ich werde versuchen, eine faire Zusammenfassung dessen zu geben, was verfügbar ist.

  1. AccUnit

    • Funktioniert nur in Access.
    • Erfordert, dass Sie Tests als seltsame Mischung aus Kommentaren und Code schreiben.(Kein Intellisense für den Kommentarteil.
    • Dort Ist eine grafische Oberfläche, die Ihnen beim Schreiben dieser seltsam aussehenden Tests hilft.
    • Das Projekt hat seit 2013 keine Updates erfahren.

  2. VB Lite-EinheitIch kann nicht sagen, dass ich es persönlich verwendet habe.Es ist verfügbar, wurde aber seit 2005 nicht mehr aktualisiert.

  3. xlEinheitxlUnit ist nicht schrecklich, aber auch nicht gut.Es ist klobig und es gibt jede Menge Standardcode.Es ist das Beste vom Schlimmsten, aber es funktioniert nicht in Access.Das ist also raus.

  4. Erstellen Sie Ihr eigenes Framework

    Ich habe Ich war dort und habe das getan.Es ist wahrscheinlich mehr, als sich die meisten Leute vorstellen wollen, aber es ist durchaus möglich, ein Unit-Testing-Framework in nativem VBA-Code zu erstellen.

  5. Das Unit-Testing-Framework des Rubberduck VBE-Add-Ins
    Haftungsausschluss:Ich bin einer der Co-Entwickler.

    Ich bin voreingenommen, aber das ist bei weitem mein Favorit von allen.

    • Kaum bis gar kein Boiler-Plate-Code.
    • Intellisense ist verfügbar.
    • Das Projekt ist aktiv.
    • Mehr Dokumentation als die meisten dieser Projekte.
    • Es funktioniert in den meisten wichtigen Office-Anwendungen, nicht nur in Access.
    • Da es sich leider um ein COM-Add-In handelt, muss es auf Ihrem Computer installiert werden.

3.Beginnen Sie mit dem Schreiben von Tests

Also zurück zu unserem Code aus Abschnitt 1.Der einzige Code, den wir Wirklich zum Testen benötigt wurde das MyModel.Reversed() Funktion.Schauen wir uns also an, wie dieser Test aussehen könnte.(Das angegebene Beispiel verwendet Rubberduck, aber es ist ein einfacher Test und könnte in das Framework Ihrer Wahl umgesetzt werden.)

'@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

Richtlinien zum Schreiben guter Tests

  1. Testen Sie jeweils nur eine Sache.
  2. Gute Tests schlagen nur dann fehl, wenn ein Fehler in das System eingeschleust wurde oder sich die Anforderungen geändert haben.
  3. Schließen Sie keine externen Abhängigkeiten wie Datenbanken und Dateisysteme ein.Diese externen Abhängigkeiten können dazu führen, dass Tests aus Gründen, auf die Sie keinen Einfluss haben, fehlschlagen.Zweitens verlangsamen sie Ihre Tests.Wenn Ihre Tests langsam sind, werden Sie sie nicht ausführen.
  4. Verwenden Sie Testnamen, die beschreiben, was der Test testet.Machen Sie sich keine Sorgen, wenn es lang wird.Am wichtigsten ist, dass es beschreibend ist.

Ich weiß, dass die Antwort etwas lang und spät war, aber ich hoffe, sie hilft einigen Leuten beim Einstieg in das Schreiben von Unit-Tests für ihren VBA-Code.

Andere Tipps

Ich habe die Antworten von Knox und David sehr geschätzt.Meine Antwort wird irgendwo zwischen ihrer liegen:mach einfach Formulare, die nicht debuggt werden müssen!

Ich denke, dass Formulare ausschließlich als das verwendet werden sollten, was sie im Grunde sind, nämlich als grafische Oberfläche nur, was hier bedeutet, dass sie nicht debuggt werden müssen!Der Debugging-Job ist dann auf Ihre VBA-Module und -Objekte beschränkt, was viel einfacher zu handhaben ist.

Es besteht natürlich eine natürliche Tendenz, VBA-Code zu Formularen und/oder Steuerelementen hinzuzufügen, insbesondere wenn Access Ihnen diese tollen „After Update“- und „On Change“-Ereignisse anbietet, aber ich rate Ihnen auf jeden Fall dazu nicht um beliebiges Formular oder steuerspezifischen Code in das Modul des Formulars einzufügen.Dies macht die weitere Wartung und Aktualisierung sehr kostspielig, da Ihr Code zwischen VBA-Modulen und Formular-/Steuermodulen aufgeteilt ist.

Dies bedeutet nicht, dass Sie dies nicht mehr verwenden können AfterUpdate Ereignis!Fügen Sie einfach Standardcode in das Ereignis ein, etwa so:

Private Sub myControl_AfterUpdate()  
    CTLAfterUpdate myControl
    On Error Resume Next
    Eval ("CTLAfterUpdate_MyForm()")
    On Error GoTo 0  
End sub

Wo:

  • CTLAfterUpdate ist eine Standardprozedur, die jedes Mal ausgeführt wird, wenn ein Steuerelement in einem Formular aktualisiert wird

  • CTLAfterUpdateMyForm ist eine bestimmte Prozedur, die jedes Mal ausgeführt wird, wenn ein Steuerelement auf MyForm aktualisiert wird

Ich habe dann 2 Module.Der erste ist

  • utilityFormEvents
    wo ich mein generisches CTLAfterUpdate-Ereignis haben werde

Der zweite ist

  • MyAppFormEvents
    Enthält den spezifischen Code aller spezifischen Formen der MyApp -Anwendung und einschließlich des CTLAFFTERUPDATEMYFORM -Verfahrens.Natürlich gibt es möglicherweise nicht, dass ctlafterUpDatemyform nicht vorhanden ist, wenn kein spezifischer Code ausgeführt werden kann.Deshalb wenden wir den "Ein Fehler" in "NEXT" um ... ...

Die Wahl einer solchen generischen Lösung bedeutet viel.Dies bedeutet, dass Sie ein hohes Maß an Code-Normalisierung erreichen (d. h. eine schmerzlose Wartung des Codes).Und wenn Sie sagen, dass Sie keinen formularspezifischen Code haben, bedeutet das auch, dass Formularmodule vollständig standardisiert sind und ihre Produktion möglich ist automatisiert:Sagen Sie einfach, welche Ereignisse Sie auf der Formular-/Kontrollebene verwalten möchten, und definieren Sie die Terminologie Ihrer generischen/spezifischen Verfahren.
Schreiben Sie ein für alle Mal Ihren Automatisierungscode.
Es erfordert ein paar Tage Arbeit, liefert aber aufregende Ergebnisse.Ich verwende diese Lösung seit 2 Jahren und sie ist eindeutig die richtige:Meine Formulare werden vollständig und automatisch von Grund auf mit einer „Formulartabelle“ erstellt, die mit einer „Steuerelementtabelle“ verknüpft ist.
Ich kann dann meine Zeit damit verbringen, an den spezifischen Verfahren des Formulars zu arbeiten, falls vorhanden.

Die Code-Normalisierung ist selbst mit MS Access ein langer Prozess.Aber es ist den Schmerz wirklich wert!

Ein weiterer Vorteil von Access ist eine COM-Anwendung ist, dass Sie eine erstellen können .NET-Anwendung zum Ausführen und Testen einer Access-Anwendung über Automatisierung.Dies hat den Vorteil, dass Sie dann ein leistungsfähigeres Test-Framework verwenden können, z NUnit um automatisierte Assert-Tests für eine Access-App zu schreiben.

Wenn Sie also entweder C# oder VB.NET in Kombination mit etwas wie NUnit beherrschen, können Sie leichter eine größere Testabdeckung für Ihre Access-App erstellen.

Obwohl das eine sehr alte Antwort ist:

Es gibt AccUnit, ein spezielles Unit-Test-Framework für Microsoft Access.

Ich habe eine Seite herausgenommen Pythons Doctest Konzeption und Implementierung einer DocTests-Prozedur in Access VBA.Dies ist offensichtlich keine vollständige Unit-Test-Lösung.Es ist noch relativ jung, daher bezweifle ich, dass ich alle Fehler beseitigt habe, aber ich denke, es ist ausgereift genug, um in die Wildnis entlassen zu werden.

Kopieren Sie einfach den folgenden Code in ein Standardcodemodul und drücken Sie F5 im Sub, um ihn in Aktion zu sehen:

'>>> 1 + 1
'2
'>>> 3 - 1
'0
Sub DocTests()
Dim Comp As Object, i As Long, CM As Object
Dim Expr As String, ExpectedResult As Variant, TestsPassed As Long, TestsFailed As Long
Dim Evaluation As Variant
    For Each Comp In Application.VBE.ActiveVBProject.VBComponents
        Set CM = Comp.CodeModule
        For i = 1 To CM.CountOfLines
            If Left(Trim(CM.Lines(i, 1)), 4) = "'>>>" Then
                Expr = Trim(Mid(CM.Lines(i, 1), 5))
                On Error Resume Next
                Evaluation = Eval(Expr)
                If Err.Number = 2425 And Comp.Type <> 1 Then
                    'The expression you entered has a function name that ''  can't find.
                    'This is not surprising because we are not in a standard code module (Comp.Type <> 1).
                    'So we will just ignore it.
                    GoTo NextLine
                ElseIf Err.Number <> 0 Then
                    Debug.Print Err.Number, Err.Description, Expr
                    GoTo NextLine
                End If
                On Error GoTo 0
                ExpectedResult = Trim(Mid(CM.Lines(i + 1, 1), InStr(CM.Lines(i + 1, 1), "'") + 1))
                Select Case ExpectedResult
                Case "True": ExpectedResult = True
                Case "False": ExpectedResult = False
                Case "Null": ExpectedResult = Null
                End Select
                Select Case TypeName(Evaluation)
                Case "Long", "Integer", "Short", "Byte", "Single", "Double", "Decimal", "Currency"
                    ExpectedResult = Eval(ExpectedResult)
                Case "Date"
                    If IsDate(ExpectedResult) Then ExpectedResult = CDate(ExpectedResult)
                End Select
                If (Evaluation = ExpectedResult) Then
                    TestsPassed = TestsPassed + 1
                ElseIf (IsNull(Evaluation) And IsNull(ExpectedResult)) Then
                    TestsPassed = TestsPassed + 1
                Else
                    Debug.Print Comp.Name; ": "; Expr; " evaluates to: "; Evaluation; " Expected: "; ExpectedResult
                    TestsFailed = TestsFailed + 1
                End If
            End If
NextLine:
        Next i
    Next Comp
    Debug.Print "Tests passed: "; TestsPassed; " of "; TestsPassed + TestsFailed
End Sub

Das Kopieren, Einfügen und Ausführen des obigen Codes aus einem Modul namens Module1 ergibt:

Module: 3 - 1 evaluates to:  2  Expected:  0 
Tests passed:  1  of  2

Ein paar kurze Anmerkungen:

  • Es gibt keine Abhängigkeiten (bei Verwendung innerhalb von Access).
  • Es nutzt aus Eval Dies ist eine Funktion im Access.Application-Objektmodell.das bedeutet du könnte Verwenden Sie es außerhalb von Access, aber es müsste ein Access.Application-Objekt erstellt und vollständig qualifiziert werden Eval Anrufe
  • Dort sind einige Eigenheiten verbunden mit Eval sich bewusst sein über
  • Es kann nur für Funktionen verwendet werden, die ein Ergebnis zurückgeben, das in eine einzelne Zeile passt

Trotz seiner Einschränkungen bin ich immer noch der Meinung, dass es ein gutes Preis-Leistungs-Verhältnis bietet.

Bearbeiten:Hier ist eine einfache Funktion mit „Doctest-Regeln“, die die Funktion erfüllen muss.

Public Function AddTwoValues(ByVal p1 As Variant, _
        ByVal p2 As Variant) As Variant
'>>> AddTwoValues(1,1)
'2
'>>> AddTwoValues(1,1) = 1
'False
'>>> AddTwoValues(1,Null)
'Null
'>>> IsError(AddTwoValues(1,"foo"))
'True

On Error GoTo ErrorHandler

    AddTwoValues = p1 + p2

ExitHere:
    On Error GoTo 0
    Exit Function

ErrorHandler:
    AddTwoValues = CVErr(Err.Number)
    GoTo ExitHere
End Function

Ich würde die Anwendung so gestalten, dass so viel Arbeit wie möglich in Abfragen und VBA-Unterroutinen erledigt wird, sodass Ihre Tests aus dem Auffüllen von Testdatenbanken, dem Ausführen von Sätzen der Produktionsabfragen und VBA für diese Datenbanken und dem anschließenden Betrachten der Ausgabe bestehen können Vergleichen Sie, um sicherzustellen, dass die Ausgabe gut ist.Bei diesem Ansatz wird die grafische Benutzeroberfläche offensichtlich nicht getestet. Daher könnten Sie den Test durch eine Reihe von Testskripten (hier meine ich ein Word-Dokument mit der Aufschrift „Öffnen Sie Formular 1 und klicken Sie auf Steuerung 1“) erweitern, die manuell ausgeführt werden.

Dies hängt vom Umfang des Projekts sowie dem für den Testaspekt erforderlichen Automatisierungsgrad ab.

Wenn Sie daran interessiert sind, Ihre Access-Anwendung auf einer detaillierteren Ebene zu testen, insbesondere den VBA-Code selbst, dann VB Lite-Einheit ist ein großartiges Unit-Test-Framework für diesen Zweck.

Ich finde, dass es in meinen Anwendungen relativ wenige Möglichkeiten für Unit-Tests gibt.Der Großteil des Codes, den ich schreibe, interagiert mit Tabellendaten oder dem Ablagesystem und ist daher grundsätzlich schwer zu testen.Schon früh habe ich einen Ansatz ausprobiert, der dem Mocking (Spoofing) ähneln könnte, bei dem ich Code erstellt habe, der einen optionalen Parameter hatte.Wenn der Parameter verwendet würde, würde die Prozedur den Parameter verwenden, anstatt Daten aus der Datenbank abzurufen.Es ist ganz einfach, einen benutzerdefinierten Typ einzurichten, der dieselben Feldtypen wie eine Datenzeile hat, und diesen an eine Funktion zu übergeben.Ich habe jetzt eine Möglichkeit, Testdaten in die Prozedur zu integrieren, die ich testen möchte.In jeder Prozedur befand sich ein Code, der die echte Datenquelle gegen die Testdatenquelle austauschte.Dadurch konnte ich Unit-Tests für eine größere Funktionsvielfalt verwenden und dabei meine eigenen Unit-Test-Funktionen verwenden.Unit-Tests zu schreiben ist einfach, es ist nur eintönig und langweilig.Am Ende gab ich die Unit-Tests auf und begann, einen anderen Ansatz zu verwenden.

Ich schreibe interne Anwendungen hauptsächlich für mich selbst, damit ich warten kann, bis Probleme auf mich zukommen, anstatt perfekten Code haben zu müssen.Wenn ich Anwendungen für Kunden schreibe, ist sich der Kunde im Allgemeinen nicht vollständig darüber im Klaren, wie viel die Softwareentwicklung kostet, sodass ich eine kostengünstige Möglichkeit brauche, um Ergebnisse zu erzielen.Beim Schreiben von Unit-Tests geht es darum, einen Test zu schreiben, der fehlerhafte Daten an eine Prozedur weiterleitet, um zu sehen, ob die Prozedur damit angemessen umgehen kann.Unit-Tests bestätigen auch, dass mit guten Daten angemessen umgegangen wird.Mein aktueller Ansatz basiert darauf, die Eingabevalidierung in jede Prozedur innerhalb einer Anwendung zu schreiben und eine Erfolgsflagge zu setzen, wenn der Code erfolgreich abgeschlossen wurde.Jede aufrufende Prozedur prüft, ob das Erfolgsflag vorhanden ist, bevor das Ergebnis verwendet wird.Wenn ein Problem auftritt, wird es in Form einer Fehlermeldung gemeldet.Jede Funktion verfügt über ein Erfolgsflag, einen Rückgabewert, eine Fehlermeldung, einen Kommentar und einen Ursprung.Ein benutzerdefinierter Typ (fr für Funktionsrückgabe) enthält die Datenelemente.Jede gegebene Funktion füllt nur einige der Datenelemente im benutzerdefinierten Typ auf.Wenn eine Funktion ausgeführt wird, gibt sie normalerweise success = true und einen Rückgabewert und manchmal einen Kommentar zurück.Wenn eine Funktion fehlschlägt, gibt sie success = false und eine Fehlermeldung zurück.Wenn eine Funktionskette fehlschlägt, werden die Fehlermeldungen zyklisch geändert, aber das Ergebnis ist tatsächlich viel besser lesbar als ein normaler Stack-Trace.Die Ursprünge sind ebenfalls verkettet, sodass ich weiß, wo das Problem aufgetreten ist.Die Anwendung stürzt selten ab und meldet alle Probleme genau.Das Ergebnis ist um einiges besser als die standardmäßige Fehlerbehandlung. 

Public Function GetOutputFolder(OutputFolder As eOutputFolder) As  FunctRet

        '///Returns a full path when provided with a target folder alias. e.g. 'temp' folder

            Dim fr As FunctRet

            Select Case OutputFolder
            Case 1
                fr.Rtn = "C:\Temp\"
                fr.Success = True
            Case 2
                fr.Rtn = TrailingSlash(Application.CurrentProject.path)
                fr.Success = True
            Case 3
                fr.EM = "Can't set custom paths – not yet implemented"
            Case Else
                fr.EM = "Unrecognised output destination requested"
            End Select

    exitproc:
        GetOutputFolder = fr

    End Function

Code erklärt.eOutputFolder ist eine benutzerdefinierte Aufzählung wie unten

Public Enum eOutputFolder
    eDefaultDirectory = 1
    eAppPath = 2
    eCustomPath = 3
End Enum

Ich verwende Enum zum Übergeben von Parametern an Funktionen, da dadurch eine begrenzte Menge bekannter Auswahlmöglichkeiten entsteht, die eine Funktion akzeptieren kann.Aufzählungen bieten auch Intelligenz bei der Eingabe von Parametern in Funktionen.Ich nehme an, dass sie eine rudimentäre Schnittstelle für eine Funktion bereitstellen.

'Type FunctRet is used as a generic means of reporting function returns
Public Type  FunctRet
    Success As Long     'Boolean flag for success, boolean not used to avoid nulls
    Rtn As Variant      'Return Value
    EM As String        'Error message
    Cmt As String       'Comments
    Origin As String    'Originating procedure/function
End Type

Ein benutzerdefinierter Typ wie FunctRet bietet auch eine hilfreiche Code-Vervollständigung.Innerhalb der Prozedur speichere ich interne Ergebnisse normalerweise in einer anonymen internen Variablen (fr), bevor ich die Ergebnisse der Rückgabevariablen (GetOutputFolder) zuweise.Dies macht Umbenennungsvorgänge sehr einfach, da nur die Ober- und Unterseite geändert werden müssen.

Zusammenfassend habe ich mit ms-access ein Framework entwickelt, das alle Vorgänge abdeckt, die VBA beinhalten.Die Tests werden dauerhaft in die Prozeduren geschrieben und sind kein Unit-Test zur Entwicklungszeit.In der Praxis läuft der Code immer noch sehr schnell.Ich achte sehr darauf, Funktionen auf niedrigerer Ebene zu optimieren, die zehntausend Mal pro Minute aufgerufen werden können.Darüber hinaus kann ich den Code während der Entwicklung in der Produktion verwenden.Wenn ein Fehler auftritt, ist dies benutzerfreundlich und die Fehlerquelle und -ursache sind in der Regel offensichtlich.Fehler werden vom aufrufenden Formular gemeldet, nicht von einem Modul in der Geschäftsschicht, was ein wichtiges Prinzip des Anwendungsdesigns ist.Darüber hinaus entfällt für mich die Last, Code für Unit-Tests zu pflegen, was wirklich wichtig ist, wenn ich ein Design entwickle, anstatt ein klar konzipiertes Design zu programmieren.

Es gibt einige potenzielle Probleme.Der Test erfolgt nicht automatisiert und neuer fehlerhafter Code wird erst erkannt, wenn die Anwendung ausgeführt wird.Der Code sieht nicht wie Standard-VBA-Code aus (er ist normalerweise kürzer).Dennoch hat der Ansatz einige Vorteile.Es ist weitaus besser, als einen Fehlerhandler nur zum Protokollieren eines Fehlers zu verwenden, da die Benutzer mich normalerweise kontaktieren und mir eine aussagekräftige Fehlermeldung übermitteln.Es kann auch Prozeduren verarbeiten, die mit externen Daten arbeiten.JavaScript erinnert mich an VBA. Ich frage mich, warum JavaScript das Land der Frameworks ist und VBA in MS-Access nicht.

Ein paar Tage nachdem ich diesen Beitrag geschrieben hatte, fand ich eine Artikel über The CodeProject das kommt dem nahe, was ich oben geschrieben habe.Der Artikel vergleicht und vergleicht die Ausnahmebehandlung und die Fehlerbehandlung.Was ich oben vorgeschlagen habe, ähnelt der Ausnahmebehandlung.

Ich habe das noch nicht versucht, aber Sie könnten es versuchen Veröffentlichen Sie Ihre Zugriffsformulare als Datenzugriffs-Webseiten auf etwas wie Sharepoint oder genauso wie Webseiten und verwenden Sie dann ein Werkzeug wie z Selen um den Browser mit einer Reihe von Tests zu steuern.

Natürlich ist dies nicht so ideal, wie den Code direkt durch Unit-Tests zu führen, aber es kann Ihnen einen Teil des Weges bringen.viel Glück

Access ist eine COM-Anwendung.Verwenden Sie COM, nicht die Windows-API.um Dinge in Access zu testen.

Die beste Testumgebung für eine Access-Anwendung ist Access.Alle Ihre Formulare/Berichte/Tabellen/Codes/Abfragen sind verfügbar, es gibt eine Skriptsprache ähnlich wie MS Test (Ok, Sie erinnern sich wahrscheinlich nicht an MS Test), es gibt eine Datenbankumgebung zum Speichern Ihrer Testskripte und Testergebnisse, und die Fähigkeiten, die Sie hier erwerben, sind auf Ihre Anwendung übertragbar.

Hier gibt es gute Vorschläge, aber ich bin überrascht, dass niemand die zentrale Fehlerverarbeitung erwähnt.Sie können Add-Ins erhalten, die eine schnelle Funktions-/Untervorlage und das Hinzufügen von Zeilennummern ermöglichen (ich verwende MZ-Tools).Senden Sie dann alle Fehler an eine einzelne Funktion, wo Sie sie protokollieren können.Sie können dann auch alle Fehler unterbrechen, indem Sie einen einzelnen Unterbrechungspunkt festlegen.

Datenzugriffsseiten werden von MS seit geraumer Zeit nicht mehr unterstützt und haben nie wirklich funktioniert (sie waren von der Installation der Office-Widgets abhängig und funktionierten nur im IE, und dann auch nur schlecht).

Es stimmt, dass Zugriffssteuerelemente, die den Fokus erhalten können, nur dann ein Fensterhandle haben, wenn sie den Fokus haben (und diejenigen, die keinen Fokus erhalten können, wie z. B. Beschriftungen, haben überhaupt kein Fensterhandle).Dies macht Access für Fenster-Handle-gesteuerte Testverfahren völlig ungeeignet.

Tatsächlich frage ich mich, warum Sie diese Art von Tests in Access durchführen möchten.Für mich klingt das wie Ihr grundlegendes Extreme Programming-Dogma, und nicht alle Prinzipien und Praktiken von XP können für die Arbeit mit Access-Anwendungen angepasst werden – quadratischer Stift, rundes Loch.

Treten Sie also einen Schritt zurück und fragen Sie sich, was Sie erreichen möchten, und bedenken Sie, dass Sie möglicherweise völlig andere Methoden verwenden müssen als diejenigen, die auf den Ansätzen basieren, die in Access einfach nicht funktionieren.

Oder ob diese Art automatisierter Tests bei einer Access-Anwendung überhaupt gültig oder sogar sinnvoll ist.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top