Wie testet man eine Sub ohne Expected Value?

[Andreas Vogt]

Hallo,
bin gerade dabei mich in das Thema einzuarbeiten.
Bei Functions die aufgerufen einen Wert zurückgeben ist das ja einfach.
Aber Subs ohne Parameter und Rückgabe, wie teste ich die?
Beispiel:

Code: Alles auswählen

Private Sub OK_Click()
    Set DB = CurrentDb
    lang = Me!Liste0
    DB.Execute "Update Sprachen set Auswahl = False"
    DB.Execute "Update Sprachen set Auswahl = True where Tabellennamen = '" & lang & "'"
    Set DB = Nothing
    DoCmd.Close acForm, Me.Name
    DoCmd.OpenForm CurrentForm
End Sub

Gut man kann einen Wert für lang vorgeben, aber z.B. wie testet man das alles korrekt gespeichert wurde?
Und wie testen ob in Me!Liste0 ein korrekter Wert steht?

Gruß Andreas

[Josef Pötzl]

Hallo Andreas!

Einen Wert für Me!Liste0 würde ich auf jeden Fall vorgeben, damit beim Test keine Zufallsauswertungen stattfinden.


Im Prinzip könnte die Test-Prozedur folgendermaßen aussehen:

Code: Alles auswählen

' 1. Formular automatisiert vorbereiten
...

' 2. Eintrag in Liste automatisiert auswählen
...

' 3. Sub ausführen (z. B. durch public machen per Compiler-Anweisung)
...

' 4. Wert(e) kontrollieren
...
 

1-2 bereitetet einen definierten Zustand vor der Sub-Ausführung auf
4. prüft, ob der gewünschte Zustand nach Sub-Ausführung erreicht wurde.

Aber:
Würdest du die Prozedur in weitere Aufgabebereich aufteilen, würde sie kontrollierter testbar werden, da das Speichern der Daten und die Datenermittlung im Formular getrennt werden könnte.

z. B.:

Code: Alles auswählen

    Private Sub OK_Click()
        SetLang  Me!Liste0
        DoCmd.Close acForm, Me.Name
        DoCmd.OpenForm CurrentForm
    End Sub

    Public Sub SetLang(byval lang as String)
        Set DB = CurrentDb
        DB.Execute "Update Sprachen set Auswahl = False"
        DB.Execute "Update Sprachen set Auswahl = True where Tabellennamen = '" & lang & "'"
        Set DB = Nothing
    End Sub

=> Das Setzen der Sprache ist eigenständigt testbar.

mfg
Josef

[Andreas Vogt]

Hallo,
wie kann ich testen ob DB.Execute richtig funktioniert hat? Den Expected Wert per DLookup holen und vergleichen?
Und wie kann ich eine Sub public machen per Compiler-Anweisung?

Andreas

[Josef Pötzl]

wie kann ich testen ob DB.Execute richtig funktioniert hat? Den Expected Wert per DLookup holen und vergleichen?

Ja, genau. Den Wert aus der Tabelle auslesen.

Und wie kann ich eine Sub public machen per Compiler-Anweisung?

z. B.:

Code: Alles auswählen

#if TESTING= 1 then
public sub xyz()
#else
private sub xyz()
#end if

...

End Sub

In den Projekteigenschaften dann TESTING auf 1 einstellen.


Ich selbst bastle mir in den Formularen aber extra einstiegspunkte, um z. B. ein Irgendwas_Click(..)-Prozedur zu öffnen.

Z.B.:

Code: Alles auswählen

private sub cmdXyz_Click()
...
end Sub

#if TESTING= 1 then
Public Sub ClickCmdXyz()
  Me.cmdXyz.SetFocus
  call cmdXyz_Click
end Sub

#end if

Damit ist der Code fürs Testen in einem Block zusammengefasst.

mfg
Josef

[Andreas Vogt]

Hallo,
habe Probleme eine Public Function eines Formulars zu testen, erhalte in dem Testklassenmodul den Fehler dass die Funktion nicht gefunden wird.
Habe daher den Test ein ein Standardmodul ausgelagert wie folgt:

Code: Alles auswählen

Public Function fktTest(MeListe0 As String) As String
    SetLang MeListe0
    fktTest = DLookup("Tabellennamen", "Sprachen", "Auswahl = True")
End Function

Meine Testklassenfunktion sieh so aus:

Code: Alles auswählen

Public Sub isSaved_true()
    Dim Expected As String
    Dim Actual As String
   
    'reset global lang
   lang = ""
   
    Expected = "Deutsch"
    Actual = fktTest("Englisch")
    Assert.That Actual, iz.Not.EqualTo(Expected)
   
    Actual = fktTest("Deutsch")
    Assert.That Actual, iz.EqualTo(Expected)
   
    Actual = fktTest("Nonsens")
    Assert.That Actual, iz.EqualTo(Expected)
End Sub

Das so zu testen ist ganz schön aufwendig, geht das nicht einfacher? Der Testaufwand ist ja größer als der eigentliche Programmieraufwand.

Gruß Andreas

[Josef Pötzl]

Hallo!

habe Probleme eine Public Function eines Formulars zu testen, erhalte in dem Testklassenmodul den Fehler dass die Funktion nicht gefunden wird.

EIne Instanz des Formulars hast du erzeugt?

Die Prozedur fktTest hättest du dir sparen können, wenn du den Code direkt in die Testprozedur einbaust.

Beispiel:

Code: Alles auswählen

'AccUnit:Row("Deutsch", "Deutsch")
'AccUnit:Row("Englisch", "Englisch")
'AccUnit:Row("Nonsens", "Deutsch")
Public Sub isSaved_true(Byval NewLang as String, Byval Expected As String)

    Dim Actual As String
   
    'reset global lang
    lang = ""  'Warum steht das in der Test-Prozedur?
   
    SetLang NewLang

    Actual = DLookup("Tabellennamen", "Sprachen", "Auswahl = True")
    Assert.That Actual, iz.EqualTo(Expected)

End Sub

Das so zu testen ist ganz schön aufwendig, geht das nicht einfacher?

Formulare zu testen ist duchaus aufwendig. Ich verzichte meistens darauf - wenn der eigentlich Arbeitscode in eine prüfbare Prozedur bzw. Klasse ausgelagert ist. Mit der Prozedur SetLang hast du doch eine gut testbare Prozedur, oder?

BTW: wenn es eine "GetLang"-Prozedur geben würde, könnte man sich auch überlegen, ob man auf das DLookup im Test verzichtet, damit der Test nicht davon abhängig wird, dass die Sprache in einer Tabelle gespeichert sein muss.

mfg
Josef

[Andreas Vogt]

Hallo,
eine Frage hätte ich noch.
Funktionieren diese Compiler-Anweisungen nur ab Acc07? Weil bei mit mit 2003 werden die ignoriert. Oder muss man in den Optionen eine Einstellung ändern?

Andreas

[Josef Pötzl]

Hallo!

Compiler-Konstanten, die über das gesamte VBA-Projekt gelten, kannst du in den Objekteigenschaften eingeben.

Compilerkonstanten.PNG (25.27 KiB) 33725-mal betrachtet

mfg
Josef