AccUnit - Benutzerbeiträge [de]

Tipps und Tricks

Josef Pötzl — Wed, 06 Sep 2023 11:50:42 GMT

Josef Pötzl:

== Bekannte Probleme ==

* Die alte Version von AccUnit mit SimplyVbUnit läuft nicht in 64-Bit Access.

Benutzeroberfläche

Josef Pötzl — Wed, 06 Sep 2023 11:48:56 GMT

Josef Pötzl:

[[en:User Interface]] __NOTOC__

Wird diese User-Interface in der neuen Version benötigt, oder reicht die Ausgabe in den Direktbereich aus?

[[Bild:AccUnit_VBE.png]]

==== Symbolleiste ====

[[Datei:AccUnit_AddIn_Commandbar_Beschreibung.png]]

==== Menüeinträge ====

[[Datei:AccUnit_AddIn_Menu_Tools.png]]
[[Datei:AccUnit_AddIn_Menu_View.png]]

==== VBE-Fenster ====
[[Datei:AccUnit_AddIn_Testauswahl.png]]

[[Datei:AccUnit_AddIn_Testergebnis.png]]

==== Dialoge ====
[[Datei:AccUnit_AddIn_TestImport.png]]
[[Datei:AccUnit_AddIn_TestExport.png]]

[[Datei:AccUnit_AddIn_UserSettings.png]]

AccUnit

Josef Pötzl — Wed, 23 Aug 2023 15:56:01 GMT

Josef Pötzl:

[[en:AccUnit]]

AccUnit ist ein Werkzeug zum Testen von Anwendungscode unter Access und VBA.

Die urspüngliche Version von AccUnit verwendete das SimplyVbUnit-Framework.<br/>
Die neue Version kommt ohne SimplyVbUnit aus und kann auch für 64-bit Access verwendet werden.

Der Quellcode der Neuentwicklung wird auf [https://github.com/AccessCodeLib/AccUnit GitHub] verwaltet.

Erste Schritte

Josef Pötzl — Wed, 23 Aug 2023 15:54:44 GMT

Josef Pötzl:

[[en:Getting started]]

Der [https://de.wikipedia.org/wiki/Softwaretest Softwaretest] ist ein wichtiger Bestandteil der Softwareentwicklung.

Während früher der Test am Ende der Softwareentwicklungszyklus als Abnahmebedingung verwendet wurde, so steht heute das Schreiben von Tests am Anfang der Programmiertätigkeiten ([https://en.wikipedia.org/wiki/Test-driven_development TDD] ).

Viele Programmiersprachen bieten heute entsprechende Tools um Test automatisiert ausführen zu lassen.
Die Programmiersprache [https://de.wikipedia.org/wiki/Visual_Basic_for_Applications VBA] enthält leider nur rudimentäre Funktionen um den Code zu testen (Debug.Print, Debug.Assert)

AccUnit bietet die Möglichkeit unter Access und anderen Office-Anwendungen, die VBA verwenden, automatisierte Tests durchzuführen. Es verwendet dazu ein in VB6 geschriebenes Zusatzmodul: SimplyVBUnit.

Die folgenden Seiten sollen Euch helfen eure ersten Tests für Eure Applikation zu schreiben.

Installation

Josef Pötzl — Fri, 18 Aug 2023 20:03:32 GMT

Josef Pötzl:

__NOTOC__ [[en:Installation]]

== Neue AccUnit Version ==

AccUnit verwendet das Access-Add-In AccUnitLoader. Nur dieses Access-Add-In muss installiert werden.

Installations-Vorgang siehe [https://github.com/AccessCodeLib/AccUnit/wiki/How-to:-Install-AccUnit GitHub-Wiki]

== AccUnit mit SimplyVbUnit (veraltet) ==

Diese Version wird nicht mehr weiterentwickelt!

===Vorbereitung===

Vor der Installation von AccUnit sollten Sie überprüfen, ob in Ihren Access- bzw. Excel-Einstellungen bei den ''Einstellungen für Makros'' die Option ''[[Zugriff auf das VBA-Projektobjektmodell vertrauen]]'' aktiviert ist (siehe auch [http://bug.access-codelib.net/view.php?id=78 Bug #78]).

===Installation===

====Installation SimplyVbUnit 3.0====
Für die Verwendung von AccUnit muss [[SimplyVBUnit|SimplyVBUnit 3.0]] installiert sein.
SimplyVBUnit ist ein in Visual Basic 6 geschriebenes Testframework.
Weitere Informationen zu SimplyVBUnit finden Sie auf
der [http://sourceforge.net/projects/simplyvbunit/ Projektseite von SimplyVBUnit auf sourceforge].

Laden Sie die Setup-Datei von SimplyVBUnit 3.0 [http://accunit.access-codelib.net/download/SimplyVBUnitSetup.zip hier] herunter.

'''''*** WICHTIG***'''''

Laden Sie NICHT die SimplyVBUnit Setup-Datei von sourceforge herunter. Diese enthält mittlerweile die Version 4 von SimplyVBUnit, die nicht mehr kompatibel zu AccUnit ist.

====Installation von AccUnit selbst====
Nach der Installation von SimplyVbUnit 3.0 können Sie [http://accunit.access-codelib.net/download/AccUnitSetup.zip AccUnitSetup.zip]
herunterladen und die Installation mit ''Setup.exe'' starten.

=== AccUnit als VBE-Add-In verwenden ===
AccUnit installiert sich als VBE AddIn im Visual Basic Editor.
Sie finden AccUnit einmal als Menüpunkt unter Extras->AccUnit
und zweitens als zusätzlich Symbolleiste mit drei Symbolen.

[[Bild:AccUnit-Menue.jpg]]

[[Datei:AccUnit_AddIn_Commandbar_Beschreibung.png]]

Installation

Josef Pötzl — Wed, 09 Aug 2023 17:26:41 GMT

Josef Pötzl:

__NOTOC__ [[en:Installation]]

== Neue AccUnit Version ==

AccUnit verwendet das Access-Add-In AccUnitLoader. Nur dieses Access-Add-In muss installiert werden.

Installations-Vorgang siehe [https://github.com/AccessCodeLib/AccUnit/wiki/How-to:-Install-AccUnit GitHub-Wiki]

== AccUnit mit SimplyVbUnit (veraltet) ==

===Vorbereitung===

Vor der Installation von AccUnit sollten Sie überprüfen, ob in Ihren Access- bzw. Excel-Einstellungen bei den ''Einstellungen für Makros'' die Option ''[[Zugriff auf das VBA-Projektobjektmodell vertrauen]]'' aktiviert ist (siehe auch [http://bug.access-codelib.net/view.php?id=78 Bug #78]).

===Installation===

====Installation SimplyVbUnit 3.0====
Für die Verwendung von AccUnit muss [[SimplyVBUnit|SimplyVBUnit 3.0]] installiert sein.
SimplyVBUnit ist ein in Visual Basic 6 geschriebenes Testframework.
Weitere Informationen zu SimplyVBUnit finden Sie auf
der [http://sourceforge.net/projects/simplyvbunit/ Projektseite von SimplyVBUnit auf sourceforge].

Laden Sie die Setup-Datei von SimplyVBUnit 3.0 [http://accunit.access-codelib.net/download/SimplyVBUnitSetup.zip hier] herunter.

'''''*** WICHTIG***'''''

Laden Sie NICHT die SimplyVBUnit Setup-Datei von sourceforge herunter. Diese enthält mittlerweile die Version 4 von SimplyVBUnit, die nicht mehr kompatibel zu AccUnit ist.

====Installation von AccUnit selbst====
Nach der Installation von SimplyVbUnit 3.0 können Sie [http://accunit.access-codelib.net/download/AccUnitSetup.zip AccUnitSetup.zip]
herunterladen und die Installation mit ''Setup.exe'' starten.

=== AccUnit als VBE-Add-In verwenden ===
AccUnit installiert sich als VBE AddIn im Visual Basic Editor.
Sie finden AccUnit einmal als Menüpunkt unter Extras->AccUnit
und zweitens als zusätzlich Symbolleiste mit drei Symbolen.

[[Bild:AccUnit-Menue.jpg]]

[[Datei:AccUnit_AddIn_Commandbar_Beschreibung.png]]

Grundlagen

Josef Pötzl — Sun, 06 Aug 2023 09:35:43 GMT

Josef Pötzl:

Quellcode

Josef Pötzl — Sat, 19 Dec 2020 19:26:53 GMT

Josef Pötzl:

[[en:Source Code]]
Der Code von AccUnit wird mittels Subversion-Quellcodeverwaltung bereitgestellt.
:SVN: https://svn.access-codelib.net/svn/accunit/
:WebSVN: https://accunit.access-codelib.net/source/listing.php?repname=AccUnit

:''Leserechte: Jeder''
:''Schreibrechte: Freischaltung erforderlich''

=== Code-Dokumenation ===

Die Code-Dokumentation wird mit Doxygen erstellt.

[https://accunit.access-codelib.net/source/doc/ Code-Dokumentation]

Erste Schritte

Josef Pötzl — Wed, 24 Jun 2015 18:22:41 GMT

Josef Pötzl:

[[en:Getting started]]

Der [http://de.wikipedia.org/wiki/Softwaretest Softwaretest] ist ein wichtiger Bestandteil der Softwareentwicklung.

Während früher der Test am Ende der Softwareentwicklungszyklus als Abnahmebedingung verwendet wurde, so steht heute das Schreiben von Tests am Anfang der Programmiertätigkeiten ([http://en.wikipedia.org/wiki/Test-driven_development TDD] ).

Viele Programmiersprachen bieten heute entsprechende Tools um Test automatisiert ausführen zu lassen.
Die Programmiersprache [http://de.wikipedia.org/wiki/Visual_Basic_for_Applications VBA] enthält leider nur rudimentäre Funktionen um den Code zu testen (Debug.Print, Debug.Assert)

AccUnit bietet die Möglichkeit unter Access und anderen Office-Anwendungen, die VBA verwenden, automatisierte Tests durchzuführen. Es verwendet dazu ein in VB6 geschriebenes Zusatzmodul: SimplyVBUnit.

Die folgenden Seiten sollen Euch helfen eure ersten Tests für Eure Applikation zu schreiben.

Erste Schritte

Josef Pötzl — Wed, 24 Jun 2015 18:22:06 GMT

Josef Pötzl:

[[en:Getting started]]

Der [http://de.wikipedia.org/wiki/Softwaretest Softwaretest] ist ein wichtiger Bestandteil der Softwareentwicklung.

Während früher der Test am Ende der Softwareentwicklungszyklus als Abnahmebedingung verwendet wurde, so steht heute das Schreiben von Tests am Anfang der Programmiertätigkeiten ([http://en.wikipedia.org/wiki/Test-driven_development TDD] ).

Viele Programmiersprachen bieten heute entsprechende Tools um Test automatisiert ausführen zu lassen.
Die Programmiersprache [http://de.wikipedia.org/wiki/Visual_Basic_for_Applications VBA] enthält leider nur rudimentäre Funktionen um den Code zu testen (Debug.Print, Debug.Assert)

AccUnit bietet die Möglichkeit unter Access und anderen Office-Anwendungen, die VBA verwenden, automatisierte Tests zu verwenden. Es verwendet dazu ein in VB6 geschriebenes Zusatzmodul: SimplyVBUnit.

Die folgenden Seiten sollen Euch helfen eure ersten Tests für Eure Applikation zu schreiben.

Installation

Josef Pötzl — Mon, 04 May 2015 16:44:21 GMT

Josef Pötzl: /* Installation SimplyVbUnit 3.0 */

__NOTOC__ [[en:Installation]]
===Vorbereitung===

Vor der Installation von AccUnit sollten Sie überprüfen, ob in Ihren Access- bzw. Excel-Einstellungen bei den ''Einstellungen für Makros'' die Option ''[[Zugriff auf das VBA-Projektobjektmodell vertrauen]]'' aktiviert ist (siehe auch [http://bug.access-codelib.net/view.php?id=78 Bug #78]).

===Installation===

====Installation SimplyVbUnit 3.0====
Für die Verwendung von AccUnit muss [[SimplyVBUnit|SimplyVBUnit 3.0]] installiert sein.
SimplyVBUnit ist ein in Visual Basic 6 geschriebenes Testframework.
Weitere Informationen zu SimplyVBUnit finden Sie auf
der [http://sourceforge.net/projects/simplyvbunit/ Projektseite von SimplyVBUnit auf sourceforge].

Laden Sie die Setup-Datei von SimplyVBUnit 3.0 [http://accunit.access-codelib.net/download/SimplyVBUnitSetup.zip hier] herunter.

'''''*** WICHTIG***'''''

Laden Sie NICHT die SimplyVBUnit Setup-Datei von sourceforge herunter. Diese enthält mittlerweile die Version 4 von SimplyVBUnit, die nicht mehr kompatibel zu AccUnit ist.

====Installation von AccUnit selbst====
Nach der Installation von SimplyVbUnit 3.0 können Sie [http://accunit.access-codelib.net/download/AccUnitSetup.zip AccUnitSetup.zip]
herunterladen und die Installation mit ''Setup.exe'' starten.

=== AccUnit als VBE-Add-In verwenden ===
AccUnit installiert sich als VBE AddIn im Visual Basic Editor.
Sie finden AccUnit einmal als Menüpunkt unter Extras->AccUnit
und zweitens als zusätzlich Symbolleiste mit drei Symbolen.

[[Bild:AccUnit-Menue.jpg]]

[[Datei:AccUnit_AddIn_Commandbar_Beschreibung.png]]

AccUnit

Josef Pötzl — Sat, 09 Nov 2013 11:21:20 GMT

Josef Pötzl:

[[en:AccUnit]]

Grundlagen

Josef Pötzl — Mon, 04 Nov 2013 08:39:33 GMT

Josef Pötzl:

[[en:Basics]] [[fr:Basics]]
Eine Software zu testen bedeutet, festzustellen, ob die Software an sie gestellte Anforderungen auch erfüllt.

Anforderungen in Umgangssprache sind jedoch nicht geeignet als Grundlage eines Tests.
( "Naja, das Ding soll halt nicht abstürzen" oder "Wenn ich da vorne 100 eingebe, dann soll da hinten irgendwas rauskommen.. " )

Zudem ist es nicht möglich komplexe Applikationen präzise zu beschreiben.

Zum Testen von Software ist es also wichtig, die große Komplexität einer Applikation in kleine testbare Programmfragmente ( = Funktionen / Prozeduren) aufzuteilen.
Diese Programmfragmente sollten dann EINE Aufgabe erledigen, so daß man dieses Programmfragment testet in dem man beschreibt:

- welches Programmfragment ( Modul, Klasse, Funktion, Sub ) teste ich
- welche Eingabewerte ( Vorbedingungen ) definiere ich
- welche Ausgabewerte ( Nachbedingungen ) erwarte ich

Unter Umständen wird es also nötig sein den bestehenden Programmcode zu überarbeiten und in kleine testbare Einheiten zu zerlegen.

[[Der erste Test]]

[[Tests erstellen]]

[[Testumgebung entfernen]]

[[Einstellungen]]

[[AccUnit-Attribute]]

AccUnit

Josef Pötzl — Mon, 04 Nov 2013 07:35:09 GMT

Josef Pötzl:

[[en:AccUnit]]
[[fr:AccUnit]]

AccUnit

Josef Pötzl — Mon, 04 Nov 2013 07:22:30 GMT

Josef Pötzl:

[[en:AccUnit]]

AccUnit

Josef Pötzl — Mon, 04 Nov 2013 07:22:14 GMT

Josef Pötzl:

[[en:AccUnit]]
[[fr:AccUnit]]

Nutzung ohne Add-In

Josef Pötzl — Wed, 16 Oct 2013 18:02:43 GMT

Josef Pötzl: /* AccUnit-Unterstützung für Debug-Fenster */

[[en:UsageWithoutAddIn]]

=== Nutzung ohne Add-In ===
''(wird nicht empfohlen)''

Die folgenden Punkte sind für die Bedienung per Add-In nicht erforderlich.

==== 1. Vorbedingung: SimplyVBUnit 3.0 ====
Damit die AccUnit-Bibliotheken funktionieren, muss [[SimplyVBUnit|SimplyVBUnit 3.0]] installiert sein.

SimplyVBUnit benötigt außerdem eine registrierte COM-dll TLBINF32.DLL. Falls Visual Studio (ab 6.0) installiert ist, sollte diese Datei bereits vorhanden und registriert sein.

==== 2. Vorbedingung: AccUnit ====
Um AccUnit im VBA-Projekt verfügbar zu machen, müssen Sie die AccUnit.Integration.dll registrieren:

In einer Kommandozeile (ggf. als Administrator):

%windir%\Microsoft.NET\Framework\v2.0.50727\regasm.exe "%pfad%\AccUnit.Integration.dll" /codebase /tlb:%pfad%\AccUnit.Integration.tlb

Den Platzhalter %pfad% müssen Sie durch den jeweiligen Pfad zu der Dll erstezen.

==== 3. Vorbedingung: Bibliotheksverweise ====

Um AccUnit im VBA-Projekt verwenden zu können müssen Sie Bibliotheksverweise auf SimplyVBUnit und AccUnit.Integration setzen (VBA-Editor: Extras-Verweise)

==== AccUnit-Unterstützung für Debug-Fenster ====
===== Konfiguration der Access-Anwendungen =====
====== Aktivieren ======
Eingabe im Direktfenster: <code>CreateObject("AccUnit.Configurator").Init VBE.ActiveVBProject</code>

Ergebnis:
* Verweise auf AccUnit und SimplyVBUnit werden gesetzt
* Hilfsklasse ''TestSuiteStarter'' und das Modul ''_AccUnitObjects'' werden eingefügt

Hinweis:
Falls es zu einem Compiler-Fehler in Access kommt, da IVBATestSuite nicht erkannt wird, bitte in den Codemodulen "AccUnitObjects" und "TestSuiteStarter" den Namen "IVBATestSuite" gegen "VBATestSuite" austauschen.
(Bug wird in nächster AccUnit-Version behoben.)

====== Entfernen ======
Eingabe im Direktfenster: <code>CreateObject("AccUnit.Configurator").Remove VBE.ActiveVBProject</code>

Die Signatur der Remove-Methode des Configurators sieht so aus (C#):
<code>Remove(VBProject activeVBProject = null, Boolean removeTestModules = false, Boolean exportModulesBeforeRemoving = true)</code>
Quelle: [https://svn.access-codelib.net/svn/accunit/trunk/src/AccUnit.Integration/Configuration/Configurator.cs]

Daher können mit folgendem Aufruf auch die Test-Module und testrelevante Module entfernt werden:
<code>CreateObject("AccUnit.Configurator").Remove VBE.ActiveVBProject, True</code>

===== Tests an TestSuite anfügen =====
Einzelne Testklassen anfügen:
* <code>TestSuite.Add(New NameDerTestKlasse)</code>
* <code>TestSuite.AddByClassName("NameDerTestKlasse")</code>

Alle Testklassen des Projekts anfügen:
* <code>TestSuite.AddFromVBProject</code>

===== Tests ausführen =====
<code>TestSuite.Run</code>

===== Tests auswerten =====
Eine Zusammenfassung der Testergebnisse ist über die Summary-Eigenschaft abrufbar:
* <code>TestSuite.Summary.Total</code>
* <code>TestSuite.Summary.Failed</code>
* <code>TestSuite.Summary.Total</code>
* ...

===== Anmerkungen =====
Die Methoden von TestSuite können auch geschachtelt verwendet werden.
z. B.: <code>TestSuite.AddFromVBProject.Run</code>

Nutzung ohne Add-In

Josef Pötzl — Wed, 16 Oct 2013 18:02:12 GMT

Josef Pötzl: /* AccUnit-Unterstützung für Debug-Fenster */

[[en:UsageWithoutAddIn]]

=== Nutzung ohne Add-In ===
''(wird nicht empfohlen)''

Die folgenden Punkte sind für die Bedienung per Add-In nicht erforderlich.

==== 1. Vorbedingung: SimplyVBUnit 3.0 ====
Damit die AccUnit-Bibliotheken funktionieren, muss [[SimplyVBUnit|SimplyVBUnit 3.0]] installiert sein.

SimplyVBUnit benötigt außerdem eine registrierte COM-dll TLBINF32.DLL. Falls Visual Studio (ab 6.0) installiert ist, sollte diese Datei bereits vorhanden und registriert sein.

==== 2. Vorbedingung: AccUnit ====
Um AccUnit im VBA-Projekt verfügbar zu machen, müssen Sie die AccUnit.Integration.dll registrieren:

In einer Kommandozeile (ggf. als Administrator):

%windir%\Microsoft.NET\Framework\v2.0.50727\regasm.exe "%pfad%\AccUnit.Integration.dll" /codebase /tlb:%pfad%\AccUnit.Integration.tlb

Den Platzhalter %pfad% müssen Sie durch den jeweiligen Pfad zu der Dll erstezen.

==== 3. Vorbedingung: Bibliotheksverweise ====

Um AccUnit im VBA-Projekt verwenden zu können müssen Sie Bibliotheksverweise auf SimplyVBUnit und AccUnit.Integration setzen (VBA-Editor: Extras-Verweise)

==== AccUnit-Unterstützung für Debug-Fenster ====
===== Konfiguration der Access-Anwendungen =====
====== Aktivieren ======
Eingabe im Direktfenster: <code>CreateObject("AccUnit.Configurator").Init VBE.ActiveVBProject</code>

Ergebnis:
* Verweise auf AccUnit und SimplyVBUnit werden gesetzt
* Hilfsklasse ''TestSuiteStarter'' und das Modul ''_AccUnitObjects'' werden eingefügt

Hinweis:
Falls es zu einem Compiler-Fehler in Access kommt, da IVBATestSuite nicht erkannt wird, bitte in den Codemodulen "AccUnitObjects" und "TestSuiteStarter" den Namen "IVBATestSuite" gegen "VBATestSuite" austauschen.
(Bug wird in nächster AccUnit-Version behoben.)

====== Entfernen ======
Eingabe im Direktfenster: <code>CreateObject("AccUnit.Configurator").Remove VBE.ActiveVBProject</code>

Die Signatur der Remove-Methode des Configurators sieht so aus (C#):
<code>Remove(VBProject activeVBProject = null, Boolean removeTestModules = false, Boolean exportModulesBeforeRemoving = true)</code>
Quelle: [https://svn.access-codelib.net/svn/accunit/trunk/src/AccUnit.Integration/Configuration/Configurator.cs]

Daher können mit folgendem Aufruf auch die Test-Module und testrelevante Module entfernt werden:
<code>CreateObject("AccUnit.Configurator").Remove VBE.ActiveVBProject, True</code>

===== Tests an TestSuite anfügen =====
Einzelne Testklassen anfügen:
* <code>TestSuite.Add(New NameDerTestKlasse)</code>
* <code>TestSuite.AddByClassName("NameDerTestKlasse")</code>

Alle Testklassen des Projekts anfügen:
* <code>TestSuite.AddFromVBProject</code>

===== Tests ausführen =====
<code>TestSuite.Run</code>

===== Tests auswerten =====
Eine Zusammenfassung der Testergebnisse ist über die Summary-Eigenschaft abrufbar:
* <code>TestSuite.Summary.Total</code>
* <code>TestSuite.Summary.Failed</code>
* <code>TestSuite.Summary.Total</code>
* ...

===== Tests auswerten =====
Die Methoden von TestSuite können auch geschachtelt verwendet werden.
z. B.: <code>TestSuite.AddFromVBProject.Run</code>

Nutzung ohne Add-In

Josef Pötzl — Wed, 16 Oct 2013 17:58:03 GMT

Josef Pötzl: /* Entfernen */

Nutzung ohne Add-In

Josef Pötzl — Wed, 16 Oct 2013 17:57:51 GMT

Josef Pötzl: /* Entfernen */

[[en:UsageWithoutAddIn]]

=== Nutzung ohne Add-In ===
''(wird nicht empfohlen)''

Die folgenden Punkte sind für die Bedienung per Add-In nicht erforderlich.

==== 1. Vorbedingung: SimplyVBUnit 3.0 ====
Damit die AccUnit-Bibliotheken funktionieren, muss [[SimplyVBUnit|SimplyVBUnit 3.0]] installiert sein.

SimplyVBUnit benötigt außerdem eine registrierte COM-dll TLBINF32.DLL. Falls Visual Studio (ab 6.0) installiert ist, sollte diese Datei bereits vorhanden und registriert sein.

==== 2. Vorbedingung: AccUnit ====
Um AccUnit im VBA-Projekt verfügbar zu machen, müssen Sie die AccUnit.Integration.dll registrieren:

In einer Kommandozeile (ggf. als Administrator):

%windir%\Microsoft.NET\Framework\v2.0.50727\regasm.exe "%pfad%\AccUnit.Integration.dll" /codebase /tlb:%pfad%\AccUnit.Integration.tlb

Den Platzhalter %pfad% müssen Sie durch den jeweiligen Pfad zu der Dll erstezen.

==== 3. Vorbedingung: Bibliotheksverweise ====

Um AccUnit im VBA-Projekt verwenden zu können müssen Sie Bibliotheksverweise auf SimplyVBUnit und AccUnit.Integration setzen (VBA-Editor: Extras-Verweise)

==== AccUnit-Unterstützung für Debug-Fenster ====
===== Konfiguration der Access-Anwendungen =====
====== Aktivieren ======
Eingabe im Direktfenster: <code>CreateObject("AccUnit.Configurator").Init VBE.ActiveVBProject</code>

Ergebnis:
* Verweise auf AccUnit und SimplyVBUnit werden gesetzt
* Hilfsklasse ''TestSuiteStarter'' und das Modul ''_AccUnitObjects'' werden eingefügt

Hinweis:
Falls es zu einem Compiler-Fehler in Access kommt, da IVBATestSuite nicht erkannt wird, bitte in den Codemodulen "AccUnitObjects" und "TestSuiteStarter" den Namen "IVBATestSuite" gegen "VBATestSuite" austauschen.
(Bug wird in nächster AccUnit-Version behoben.)

====== Entfernen ======
Eingabe im Direktfenster: <code>CreateObject("AccUnit.Configurator").Remove VBE.ActiveVBProject</code>

Die Signatur der Remove-Methode des Configurators sieht so aus (C#):

<code>Remove(VBProject activeVBProject = null, Boolean removeTestModules = false, Boolean exportModulesBeforeRemoving = true)</code>
Quelle: [https://svn.access-codelib.net/svn/accunit/trunk/src/AccUnit.Integration/Configuration/Configurator.cs]

Daher können mit folgendem Aufruf auch die Test-Module und testrelevante Module entfernt werden:
<code>CreateObject("AccUnit.Configurator").Remove VBE.ActiveVBProject, True</code>

===== Tests an TestSuite anfügen =====
Einzelne Testklassen anfügen:
* <code>TestSuite.Add(New NameDerTestKlasse)</code>
* <code>TestSuite.AddByClassName("NameDerTestKlasse")</code>

Alle Testklassen des Projekts anfügen:
* <code>TestSuite.AddFromVBProject</code>

===== Tests ausführen =====
<code>TestSuite.Run</code>

===== Tests auswerten =====
Eine Zusammenfassung der Testergebnisse ist über die Summary-Eigenschaft abrufbar:
* <code>TestSuite.Summary.Total</code>
* <code>TestSuite.Summary.Failed</code>
* <code>TestSuite.Summary.Total</code>
* ...

Nutzung ohne Add-In

Josef Pötzl — Wed, 16 Oct 2013 17:57:32 GMT

Josef Pötzl:

Nutzung ohne Add-In

Josef Pötzl — Wed, 16 Oct 2013 17:56:46 GMT

Josef Pötzl:

[[en:UsageWithoutAddIn]]

=== Nutzung ohne Add-In ===
''(wird nicht empfohlen)''

Die folgenden Punkte sind für die Bedienung per Add-In nicht erforderlich.

==== 1. Vorbedingung: SimplyVBUnit 3.0 ====
Damit die AccUnit-Bibliotheken funktionieren, muss [[SimplyVBUnit|SimplyVBUnit 3.0]] installiert sein.

SimplyVBUnit benötigt außerdem eine registrierte COM-dll TLBINF32.DLL. Falls Visual Studio (ab 6.0) installiert ist, sollte diese Datei bereits vorhanden und registriert sein.

==== 2. Vorbedingung: AccUnit ====
Um AccUnit im VBA-Projekt verfügbar zu machen, müssen Sie die AccUnit.Integration.dll registrieren:

In einer Kommandozeile (ggf. als Administrator):

%windir%\Microsoft.NET\Framework\v2.0.50727\regasm.exe "%pfad%\AccUnit.Integration.dll" /codebase /tlb:%pfad%\AccUnit.Integration.tlb

Den Platzhalter %pfad% müssen Sie durch den jeweiligen Pfad zu der Dll erstezen.

==== 3. Vorbedingung: Bibliotheksverweise ====

Um AccUnit im VBA-Projekt verwenden zu können müssen Sie Bibliotheksverweise auf SimplyVBUnit und AccUnit.Integration setzen (VBA-Editor: Extras-Verweise)

==== AccUnit-Unterstützung für Debug-Fenster ====
===== Konfiguration der Access-Anwendungen =====
====== Aktivieren ======
Eingabe im Direktfenster: <code>CreateObject("AccUnit.Configurator").Init VBE.ActiveVBProject</code>

Ergebnis:
* Verweise auf AccUnit und SimplyVBUnit werden gesetzt
* Hilfsklasse ''TestSuiteStarter'' und das Modul ''_AccUnitObjects'' werden eingefügt

Hinweis:
Falls es zu einem Compiler-Fehler in Access kommt, da IVBATestSuite nicht erkannt wird, bitte in den Codemodulen "AccUnitObjects" und "TestSuiteStarter" den Namen "IVBATestSuite" gegen "VBATestSuite" austauschen.
(Bug wird in nächster AccUnit-Version behoben.)

====== Entfernen ======
Eingabe im Direktfenster: <code>CreateObject("AccUnit.Configurator").Remove VBE.ActiveVBProject</code>

Die Signatur der Remove-Methode des Configurators sieht so aus (C#):
<code>Remove(VBProject activeVBProject = null, Boolean removeTestModules = false, Boolean exportModulesBeforeRemoving = true)</code>
Quelle: [https://svn.access-codelib.net/svn/accunit/trunk/src/AccUnit.Integration/Configuration/Configurator.cs]

Daher können mit folgendem Aufruf auch die Test-Module und testrelevante Module entfernt werden:
<code>CreateObject("AccUnit.Configurator").Remove VBE.ActiveVBProject, True</code>

===== Tests an TestSuite anfügen =====
Einzelne Testklassen anfügen:
* TestSuite.Add(New NameDerTestKlasse)
* TestSuite.AddByClassName("NameDerTestKlasse")

Alle Testklassen des Projekts anfügen:
* TestSuite.AddFromVBProject

===== Tests ausführen =====
TestSuite.Run

===== Tests auswerten =====
Eine Zusammenfassung der Testergebnisse ist über die Summary-Eigenschaft abrufbar:
* TestSuite.Summary.Total
* TestSuite.Summary.Failed
* TestSuite.Summary.Total
* ...

Nutzung ohne Add-In

Josef Pötzl — Wed, 16 Oct 2013 17:50:35 GMT

Josef Pötzl: /* Aktivieren */

Testumgebung entfernen

Josef Pötzl — Tue, 22 May 2012 18:06:00 GMT

Josef Pötzl: /* Entfernen einzelner Testklassen */

== Entfernen der Testumgebung ==

=== Die Testumgebung vollständig entfernen ===

Über das [[Benutzeroberfläche#Menüeinträge|Menü]] ''Extras >> AccUnit-de >> Testumgebung entfernen'' werden alle Testklassen sowie die durch AccUnit hinzugefügten [[Verweise]] automatisch entfernt. In diesem Fall wird im aktuellen Arbeitsverzeichnis ein Ordner "[[Einstellungen|Tests]]" erzeugt, welcher ein Backup alle Ihrer Testklassen enthält.

Sofern Sie den Ordner "Tests" nicht löschen, können Sie die Testumgebung wiederherstellen, indem Sie im [[Benutzeroberfläche#Menüeinträge|Menü]] ''Extras >> AccUnit-de >> Tests importieren'' wählen.

=== Entfernen einzelner Testklassen ===

Testklassen können über das [[Benutzeroberfläche#Menüeinträge|Menü]] ''Extras >> AccUnit-de >> Tests exportieren'' in den Import/Export-Ordner exportiert und aus der Anwendung entfernt werden.

Wenn Sie einzelne Testklassen komplett entfernen (direktes Löschen im VBA-Editor), erhalten Sie beim nächsten Kompilieren eine Fehlermeldung. Sie müssen in diesem Fall im Modul ''AccessUnit_TestClassFactory'' die zugehörige Funktion entfernen, welche die Instanz der gelöschte Testklasse erzeugt hat.

Alternativ können Sie auch das komplette Modul ''AccessUnit_TestClassFactory'' entfernen. Es wird automatisch beim nächsten Lauf von AccUnit wiederhergestellt.

=== Entfernen einzelner Tests ===

Einzelne Tests können in der jeweiligen Testklasse einfach gelöscht werden. Enthält eine Ihrer Testklassen keine Testmethode mehr, so wird diese im Fenster ''AccUnit Test-Liste'' mit einem Fragezeichen-Symbol dargestellt.

Testumgebung entfernen

Josef Pötzl — Tue, 22 May 2012 18:04:51 GMT

Josef Pötzl: /* Entfernen einzelner Testklassen */

== Entfernen der Testumgebung ==

=== Die Testumgebung vollständig entfernen ===

Über das [[Benutzeroberfläche#Menüeinträge|Menü]] ''Extras >> AccUnit-de >> Testumgebung entfernen'' werden alle Testklassen sowie die durch AccUnit hinzugefügten [[Verweise]] automatisch entfernt. In diesem Fall wird im aktuellen Arbeitsverzeichnis ein Ordner "[[Einstellungen|Tests]]" erzeugt, welcher ein Backup alle Ihrer Testklassen enthält.

Sofern Sie den Ordner "Tests" nicht löschen, können Sie die Testumgebung wiederherstellen, indem Sie im [[Benutzeroberfläche#Menüeinträge|Menü]] ''Extras >> AccUnit-de >> Tests importieren'' wählen.

=== Entfernen einzelner Testklassen ===

Einzelne Tests können über das [[Benutzeroberfläche#Menüeinträge|Menü]] ''Extras >> AccUnit-de >> Tests exportieren'' in den Import/Export-Ordner exportiert und aus der Anwendung entfernt werden.

Wenn Sie einzelne Testklassen komplett entfernen (direktes Löschen im VBA-Editor), erhalten Sie beim nächsten Kompilieren eine Fehlermeldung. Sie müssen in diesem Fall im Modul ''AccessUnit_TestClassFactory'' die zugehörige Funktion entfernen, welche die Instanz der gelöschte Testklasse erzeugt hat.

Alternativ können Sie auch das komplette Modul ''AccessUnit_TestClassFactory'' entfernen. Es wird automatisch beim nächsten Lauf von AccUnit wiederhergestellt.

=== Entfernen einzelner Tests ===

Einzelne Tests können in der jeweiligen Testklasse einfach gelöscht werden. Enthält eine Ihrer Testklassen keine Testmethode mehr, so wird diese im Fenster ''AccUnit Test-Liste'' mit einem Fragezeichen-Symbol dargestellt.

Testumgebung entfernen

Josef Pötzl — Tue, 22 May 2012 18:04:09 GMT

Josef Pötzl:

== Entfernen der Testumgebung ==

=== Die Testumgebung vollständig entfernen ===

Über das [[Benutzeroberfläche#Menüeinträge|Menü]] ''Extras >> AccUnit-de >> Testumgebung entfernen'' werden alle Testklassen sowie die durch AccUnit hinzugefügten [[Verweise]] automatisch entfernt. In diesem Fall wird im aktuellen Arbeitsverzeichnis ein Ordner "[[Einstellungen|Tests]]" erzeugt, welcher ein Backup alle Ihrer Testklassen enthält.

Sofern Sie den Ordner "Tests" nicht löschen, können Sie die Testumgebung wiederherstellen, indem Sie im [[Benutzeroberfläche#Menüeinträge|Menü]] ''Extras >> AccUnit-de >> Tests importieren'' wählen.

=== Entfernen einzelner Testklassen ===

Einzelne Tests können über das [[Benutzeroberfläche#Menüeinträge|Menü]] ''Extras >> AccUnit-de >> Tests exportieren'' in den Export-Ordner exportiert und aus der Anwendung entfernt werden.

Wenn Sie einzelne Testklassen komplett entfernen (direktes Löschen im VBA-Editor), erhalten Sie beim nächsten Kompilieren eine Fehlermeldung. Sie müssen in diesem Fall im Modul ''AccessUnit_TestClassFactory'' die zugehörige Funktion entfernen, welche die Instanz der gelöschte Testklasse erzeugt hat.

Alternativ können Sie auch das komplette Modul ''AccessUnit_TestClassFactory'' entfernen. Es wird automatisch beim nächsten Lauf von AccUnit wiederhergestellt.

=== Entfernen einzelner Tests ===

Einzelne Tests können in der jeweiligen Testklasse einfach gelöscht werden. Enthält eine Ihrer Testklassen keine Testmethode mehr, so wird diese im Fenster ''AccUnit Test-Liste'' mit einem Fragezeichen-Symbol dargestellt.

NewTestRunner

Josef Pötzl — Sat, 14 Jan 2012 17:54:19 GMT

Josef Pötzl:

[[en:NewTestRunner]]

[[Datei:AccUnit_TestRunner_Draft.jpg|480px]]

Details siehe [http://en.accunit.access-codelib.net/NewTestRunner englische Version]

NewTestRunner

Josef Pötzl — Sat, 14 Jan 2012 17:53:45 GMT

Josef Pötzl:

[[en:NewTestRunner]]

Details siehe [http://en.accunit.access-codelib.net/NewTestRunner englische Version]

[[Datei:AccUnit_TestRunner_Draft.jpg|480px]]

NewTestRunner

Josef Pötzl — Sat, 14 Jan 2012 17:53:35 GMT

Josef Pötzl:

[[en:NewTestRunner]]

Details siehe [http://en.accunit.access-codelib.net/NewTestRunner englische Version ]

[[Datei:AccUnit_TestRunner_Draft.jpg|480px]]

NewTestRunner

Josef Pötzl — Sat, 14 Jan 2012 17:53:14 GMT

Josef Pötzl:

[[en:NewTestRunner]]

Details siehe englische Version [http://en.accunit.access-codelib.net/NewTestRunner]

[[Datei:AccUnit_TestRunner_Draft.jpg|480px]]

NewTestRunner

Josef Pötzl — Sat, 14 Jan 2012 17:51:13 GMT

Josef Pötzl:

[[en:NewTestRunner]]

Details siehe englische Version

[[Datei:AccUnit_TestRunner_Draft.jpg|480px]]

NewTestRunner

Josef Pötzl — Sat, 14 Jan 2012 17:49:49 GMT

Josef Pötzl: Der Seiteninhalt wurde durch einen anderen Text ersetzt: „en:NewTestRunner“

[[en:NewTestRunner]]

NewTestRunner

Josef Pötzl — Sat, 14 Jan 2012 17:49:34 GMT

Josef Pötzl:

[[en:NewTestRunner]]
This is a first draft for an AccUnit TestRunner.

[[Datei:AccUnit_TestRunner_Draft.jpg|480px]]

== Details ==

(Gathered mainly as results of the discussion between Josef and Paul on Jan 13th, 2012)

TO BE ORDERED AND REVIEWED

=== Reponsibilites and Input/Output ===

* '''TestManager'''
** Responsibility: Orchestrates the parts described below
** Responsibilites in particular:
*** A2: listening to TestCollector and maintaing the list of test related info in the repository
*** B0: instantiates the TestRunner for each new test run
*** B1: providing a list of tests to be run by the TestRunner
**** some sources: all tests from the repository, selection from a test tree, test according to the current selection of the IDE, a prioritizer component, selection by tags, ...)
*** B3: creating an instance for the current TestRun (actually before starting)
*** B2: starting the TestRunner (as reaction to some user action)
*** B4: listening to the outputs of the TestRunner and maintaining the current TestRun object
*** B5: adding the current TestRun object to the list of test runs in the repository
** TO BE CLARIFIED: Should this work as a facade?
** Events:
*** BeforeCollectingTests (maybe better: BeforeScanningProject? - there are also the test-related modules)
*** AfterCollectingTests (maybe better: AfterScanningProject? - reasoning as above)
*** AddedTestRunToRepository(ITestRun)

* '''TestCollector'''
** Responsibility: Collects the relevant information for running tests. (rephrased: In order to run a test, no one has to go back to the VBProject to look up something)
** Input: Events from a component in VbeProjectManagement or just a list of all modules in the VBProject
** Output: IObservable<ITest>/Events
*** FoundTestMethod(ITest)
*** LostTestMethod(ITest)
*** FoundTestRelatedMethod(IAttributedMethod)
*** LostTestRelatedMethod(IAttributedMethod)
** maybe better name: ProjectScanner
*** there are not just the test classes itself, but also the test-related modules
** TestManager listens to the output and maintains the list of all test related info in the repository

* '''Repository.AllTests'''
** Responsibility: Represents the current structure of the VBProject with respect to tests
** Flat list (no fixture-tests hierarchy), hierarchies must be derived by UI components
** Input: Method calls by the TestManager
** Output: Enumeration/IObservable<ITest>/Events:
*** AddedTest(ITest)
*** RemovedTest(ITest)
*** Cleared

* '''Repository.TestRelated''' (NOT IN THE DRAWING)
** Responsibility: Represents all modules in the VBProject that are just test-related, but not actually test fixtures.
** global info needed by the TestRunner
** Input: method calls by the TestManager in reaction to events from TestCollector
** Output: none
** The TestManager instantiates the TestRunner for each run with this information

* '''TestRunner'''
** Responsibility: Coordinates the calls to the methods of the test suite (tests and tag hook handler)
** Note: Its the TestExecutor that actually invokes the methods via COM, not the TestRunner!
** Input:
*** List of tests (subset of test in Repository.AllTests)
*** List of test related modules (Repository.TestRelated)
** Output: IObservable<ITestResult>/Events
*** StartingTestRun(bool cancel)
*** StartedTestRun(ITestRun)
*** TagSetChanged(IEnumerable<ITagChangeInfo>)
*** FinishedTestRun(ITestRun)
*** ITestRun steadiliy populated during the test run
** The calling of tag hook handlers (see below) is also managed by the TestRunner

* '''TestExecutor'''
** Responsibility: Is able to instantiate classes and invoke methods and understands exceptions from failed assertions
* Input:
** name of the class to instantiate/terminate
** name of the method to execute (along with parameters in the case of a call for a row test)
** Don't use ITest to pass the input parameters.
*** That's too much (attributes not needed generally, rowdata needed without name of the row or ignored state)
*** DIFFERENT FROM THE DRAWING
* Output:
** True: method call succeeded
** False: an assertion failed (assertion message is provided to the TestRunner)
** Non-Assert exceptions are passed to the TestRunner as is
*** Future extension point: special handling for exceptions

=== Conceptual ===

* No support of FixtureSetup/FixtureTeardown
** Seldom used, and when, then often misused (violating independency of tests)
** More global setup/cleanup (as setting up backend for test) via tag-hooks

* Tags applied on module level inherit to all children (test methods and rows in row tests)

* Support for tag hierarchies?
** path notation: e.g. DatabaseTests/ADO/Oracle

* No guarantee how often a test class will be instantiated during a test run
** discourage to use class scope (Initialize/Terminate and Fields)

* Tag Hooks
** Every time a tag appears during a test run, a setup tag-hook is called (if available)
** Every time a tag vanishes during a test run, a teardown tag-hook is called (if available)
** Tag hook handler
*** reside in class modules annotated with AccUnit:TestRelated
*** are tagged with AccUnit:Setup("MyTag"), and AccUnit:Teardown("MyTag"), resp.

* Test related modules (AccUnit:TestRelated) can be standard modules or class modules
** Test related modules with tag hooks (AccUnit:Setup("MyTag"), AccUnit:Teardown("MyTag")) must reside in class modules
*** This helps to avoid global state enduring over the end of a test run (still could be done by copy state to fields in standard module)

=== Technical ===

* New assembly AccUnit.Framework
** No References to COM (SimplyVbUnit/Access/TLI)

* No IFixture
** By now, no relevant information besides the name
** The name of the fixture is a property of ITest

* AccUnit:Rollback and AccUnit:ClickingMsgBox implemented as kind of plugins to the structure

=== Data structures ===

* IAttributedMethod
** modulename
** methodname
** attributes

* ITest
** fixturename
** methodname
** attributes
** tags (specialized subset of attributes)
** rowdata (specialized subset of attributes)

* ITestRun
** ProjectInfo (Name of the file, version info?, ...)
** List<ITestResult>
** State (prepared, running, finished, canceled, aborted)
** StartedAt
** EndedAt
** Summary

* ITagChangeInfo
** Tag (string)
** Change (appeared/disappeared)

*ITestResult
** ITest
** status (success, failed, error, ignored) ... error = runtime error; failed = error by asserts
** message (??? rowtest: summary or null ?)
** rowdata (testresults of rows)
** StartedAt
** EndedAt
** Summary ??? ... summary of row tests?

=== Open issues ===
* Test Reactive Extensions in a VBE AddIn

NewTestRunner

Josef Pötzl — Sat, 14 Jan 2012 17:48:46 GMT

Josef Pötzl: /* Data structures */

This is a first draft for an AccUnit TestRunner.

[[Datei:AccUnit_TestRunner_Draft.jpg|480px]]

== Details ==

(Gathered mainly as results of the discussion between Josef and Paul on Jan 13th, 2012)

TO BE ORDERED AND REVIEWED

=== Reponsibilites and Input/Output ===

* '''TestManager'''
** Responsibility: Orchestrates the parts described below
** Responsibilites in particular:
*** A2: listening to TestCollector and maintaing the list of test related info in the repository
*** B0: instantiates the TestRunner for each new test run
*** B1: providing a list of tests to be run by the TestRunner
**** some sources: all tests from the repository, selection from a test tree, test according to the current selection of the IDE, a prioritizer component, selection by tags, ...)
*** B3: creating an instance for the current TestRun (actually before starting)
*** B2: starting the TestRunner (as reaction to some user action)
*** B4: listening to the outputs of the TestRunner and maintaining the current TestRun object
*** B5: adding the current TestRun object to the list of test runs in the repository
** TO BE CLARIFIED: Should this work as a facade?
** Events:
*** BeforeCollectingTests (maybe better: BeforeScanningProject? - there are also the test-related modules)
*** AfterCollectingTests (maybe better: AfterScanningProject? - reasoning as above)
*** AddedTestRunToRepository(ITestRun)

* '''TestCollector'''
** Responsibility: Collects the relevant information for running tests. (rephrased: In order to run a test, no one has to go back to the VBProject to look up something)
** Input: Events from a component in VbeProjectManagement or just a list of all modules in the VBProject
** Output: IObservable<ITest>/Events
*** FoundTestMethod(ITest)
*** LostTestMethod(ITest)
*** FoundTestRelatedMethod(IAttributedMethod)
*** LostTestRelatedMethod(IAttributedMethod)
** maybe better name: ProjectScanner
*** there are not just the test classes itself, but also the test-related modules
** TestManager listens to the output and maintains the list of all test related info in the repository

* '''Repository.AllTests'''
** Responsibility: Represents the current structure of the VBProject with respect to tests
** Flat list (no fixture-tests hierarchy), hierarchies must be derived by UI components
** Input: Method calls by the TestManager
** Output: Enumeration/IObservable<ITest>/Events:
*** AddedTest(ITest)
*** RemovedTest(ITest)
*** Cleared

* '''Repository.TestRelated''' (NOT IN THE DRAWING)
** Responsibility: Represents all modules in the VBProject that are just test-related, but not actually test fixtures.
** global info needed by the TestRunner
** Input: method calls by the TestManager in reaction to events from TestCollector
** Output: none
** The TestManager instantiates the TestRunner for each run with this information

* '''TestRunner'''
** Responsibility: Coordinates the calls to the methods of the test suite (tests and tag hook handler)
** Note: Its the TestExecutor that actually invokes the methods via COM, not the TestRunner!
** Input:
*** List of tests (subset of test in Repository.AllTests)
*** List of test related modules (Repository.TestRelated)
** Output: IObservable<ITestResult>/Events
*** StartingTestRun(bool cancel)
*** StartedTestRun(ITestRun)
*** TagSetChanged(IEnumerable<ITagChangeInfo>)
*** FinishedTestRun(ITestRun)
*** ITestRun steadiliy populated during the test run
** The calling of tag hook handlers (see below) is also managed by the TestRunner

* '''TestExecutor'''
** Responsibility: Is able to instantiate classes and invoke methods and understands exceptions from failed assertions
* Input:
** name of the class to instantiate/terminate
** name of the method to execute (along with parameters in the case of a call for a row test)
** Don't use ITest to pass the input parameters.
*** That's too much (attributes not needed generally, rowdata needed without name of the row or ignored state)
*** DIFFERENT FROM THE DRAWING
* Output:
** True: method call succeeded
** False: an assertion failed (assertion message is provided to the TestRunner)
** Non-Assert exceptions are passed to the TestRunner as is
*** Future extension point: special handling for exceptions

=== Conceptual ===

* No support of FixtureSetup/FixtureTeardown
** Seldom used, and when, then often misused (violating independency of tests)
** More global setup/cleanup (as setting up backend for test) via tag-hooks

* Tags applied on module level inherit to all children (test methods and rows in row tests)

* Support for tag hierarchies?
** path notation: e.g. DatabaseTests/ADO/Oracle

* No guarantee how often a test class will be instantiated during a test run
** discourage to use class scope (Initialize/Terminate and Fields)

* Tag Hooks
** Every time a tag appears during a test run, a setup tag-hook is called (if available)
** Every time a tag vanishes during a test run, a teardown tag-hook is called (if available)
** Tag hook handler
*** reside in class modules annotated with AccUnit:TestRelated
*** are tagged with AccUnit:Setup("MyTag"), and AccUnit:Teardown("MyTag"), resp.

* Test related modules (AccUnit:TestRelated) can be standard modules or class modules
** Test related modules with tag hooks (AccUnit:Setup("MyTag"), AccUnit:Teardown("MyTag")) must reside in class modules
*** This helps to avoid global state enduring over the end of a test run (still could be done by copy state to fields in standard module)

=== Technical ===

* New assembly AccUnit.Framework
** No References to COM (SimplyVbUnit/Access/TLI)

* No IFixture
** By now, no relevant information besides the name
** The name of the fixture is a property of ITest

* AccUnit:Rollback and AccUnit:ClickingMsgBox implemented as kind of plugins to the structure

=== Data structures ===

* IAttributedMethod
** modulename
** methodname
** attributes

* ITest
** fixturename
** methodname
** attributes
** tags (specialized subset of attributes)
** rowdata (specialized subset of attributes)

* ITestRun
** ProjectInfo (Name of the file, version info?, ...)
** List<ITestResult>
** State (prepared, running, finished, canceled, aborted)
** StartedAt
** EndedAt
** Summary

* ITagChangeInfo
** Tag (string)
** Change (appeared/disappeared)

*ITestResult
** ITest
** status (success, failed, error, ignored) ... error = runtime error; failed = error by asserts
** message (??? rowtest: summary or null ?)
** rowdata (testresults of rows)
** StartedAt
** EndedAt
** Summary ??? ... summary of row tests?

=== Open issues ===
* Test Reactive Extensions in a VBE AddIn

Testen mit vbWatchdog

Josef Pötzl — Wed, 21 Dec 2011 19:54:09 GMT

Josef Pötzl:

[[en:Testing with vbWatchdog]]
Ab Version 2.3.2 kann vbWatchdog für Tests aktiviert bleiben. Allerdings muss die ErrEx-Eigenschaft <code>PropagateUnhandledClassErrors</code> eingestellt werden. Die Konfiguration kann über Setup/TearDown erfolgen.

1. Variante (eventuell langsam)
<source>
Public Sub Setup()
EnableWatchdog
ErrEx.PropagateUnhandledClassErrors = True
End Sub

Public Sub TearDown()
DisableWatchdog
ErrEx.PropagateUnhandledClassErrors = False
End Sub
</source>

2. Variante (schneller, aber ohne DisableWatchdog! ... z. B. für Row-Tests)
<source>
Public Sub FixtureSetup()
EnableWatchdog
End Sub

Public Sub Setup()
ErrEx.PropagateUnhandledClassErrors = True
End Sub

Public Sub TearDown()
ErrEx.PropagateUnhandledClassErrors = False
End Sub

'Public Sub FixtureTeardown()
'' läuft wegen Bug in SimplyVBUnit bereits nach erstem Test ab
'' ... daher leider nicht verwendbar
' DisableWatchdog
'End Sub
'
</source>

Testen mit vbWatchdog

Josef Pötzl — Wed, 21 Dec 2011 19:53:46 GMT

Josef Pötzl:

[[en:Testing with vbWatchdog]]
Ab Version 2.3.2 kann vbWatchdog für Tests aktiviert bleiben. Allerdings muss die ErrEx-Eigenschaft <code>PropagateUnhandledClassErrors</code> eingestellt werden. Die Konfiguration kann über Setup/TearDown erfolgen.

1. Variante (eventuell langsam)
<source>
Public Sub Setup()
EnableWatchdog
ErrEx.PropagateUnhandledClassErrors = True
End Sub

Public Sub TearDown()
DisableWatchdog
ErrEx.PropagateUnhandledClassErrors = False
End Sub
</source>

2. Variante (schneller, aber ohne DisableWatchdog! ... z. B. für Row-Tests)
<source>
Public Sub FixtureSetup()
EnableWatchdog
End Sub

Public Sub Setup()
ErrEx.PropagateUnhandledClassErrors = True
End Sub

Public Sub TearDown()
ErrEx.PropagateUnhandledClassErrors = False
End Sub

Public Sub FixtureTeardown()
'' läuft wegen Bug in SimplyVBUnit bereits nach erstem Test ab
'' ... daher leider nicht verwendbar
' DisableWatchdog
End Sub

</source>

Testen mit vbWatchdog

Josef Pötzl — Wed, 21 Dec 2011 19:53:33 GMT

Josef Pötzl:

Testen mit vbWatchdog

Josef Pötzl — Wed, 21 Dec 2011 19:52:02 GMT

Josef Pötzl:

AccUnit-Attribute

Josef Pötzl — Fri, 11 Mar 2011 17:56:29 GMT

Josef Pötzl:

__NOTOC__
== AccUnit:TestClass ==
Markiert eine Klasse als Testklasse.

==== Syntax ====
<source>' AccUnit:TestClass</source>

==== Verwendbar in ====
* Deklarationsbereich einer Klasse

== AccUnit:TestRelated ==
Markiert eine Klasse, Standardmodul bzw. Formulare/Berichte als Hilfsmodule für Tests. Diese Codemodule bzw. Formulare/Berichte können wie Testklassen importiert bzw. exportiert werden.

==== Syntax ====
<source>' AccUnit:TestRelated </source>

==== Verwendbar in ====
* Deklarationsbereich einer Klasse
* Deklarationsbereich eines Standardmoduls
* Deklarationsbereich eines Formular- oder Bericht-Moduls

== AccUnit:Row ==
Übergabe der Row-Test-Parameter

==== Syntax ====
<source>' AccUnit:Row(Param1, Param2)</source>

==== Verwendbar in ====
* Deklarationsbereich einer Testmethode

== AccUnit:Tags ==
Markiert Testklassen bzw. Testmethoden. Kann zum Filtern der Tests verwendet werden.

==== Syntax ====
<source>' AccUnit:Tags(Tag1, Tag2, Tag3)</source>

==== Verwendbar in ====
* Deklarationsbereich einer Testklasse
* Deklarationsbereich einer Testmethode

== AccUnit:Ignore ==
Testklasse oder Methode nicht ausführen.

==== Syntax ====
<source>' AccUnit:Ignore
' AccUnit:Ignore(Comment)
' AccUnit:Row(Param1, Param2).Ignore(Comment)</source>

==== Verwendbar in ====
* Deklarationsbereich einer Klasse
* Deklarationsbereich einer Testmethode
* Erweiterung des Row-Attributs

== AccUnit:ClickingMsgBox ==

Mausklicks für Msgbox-Ersatzfunktion

==== Syntax ====
<source>' AccUnit:ClickingMsgBox(vbYes, vbOk, vbNo)
' AccUnit:Row(Param1, Param2).ClickingMsgBox(vbYes, vbOk, vbNo))</source>

==== Verwendbar in ====
* Deklarationsbereich einer Testmethode
* Erweiterung des Row-Attributs

AccUnit-Attribute

Josef Pötzl — Fri, 11 Mar 2011 16:56:44 GMT

Josef Pötzl:

__NOTOC__
== AccUnit:TestClass ==
Markiert eine Klasse als Testklasse.

==== Syntax ====
<source>' AccUnit:TestClass</source>

==== Verwendbar in ====
* Deklarationsbereich einer Klasse

== AccUnit:TestRelated ==
Markiert eine Klasse, Standardmodul bzw. Formulare/Berichte als Hilfsmodule für Tests. Diese Codemodule bzw. Formulare/Berichte können wie Testklassen importiert bzw. exportiert werden.

==== Syntax ====
<source>' AccUnit:TestRelated </source>

==== Verwendbar in ====
* Deklarationsbereich einer Klasse
* Deklarationsbereich eines Standardmoduls
* Deklarationsbereich eines Formular- oder Bericht-Moduls

== AccUnit:Row ==
Übergabe der Row-Test-Parameter

==== Syntax ====
<source>' AccUnit:Row(Param1, Param2)</source>

==== Verwendbar in ====
* Deklarationsbereich einer Testmethode

== AccUnit:Tags ==
Markiert Testklassen bzw. Testmethoden. Kann zum Filtern der Tests verwendet werden.

==== Syntax ====
<source>' AccUnit:Tags(Tag1, Tag2, Tag3)</source>

==== Verwendbar in ====
* Deklarationsbereich einer Testklasse
* Deklarationsbereich einer Testmethode
* Erweiterung des Row-Attributs

== AccUnit:Ignore ==
Testklasse oder Methode nicht ausführen.

==== Syntax ====
<source>' AccUnit:Ignore(Comment)</source>

==== Verwendbar in ====
* Deklarationsbereich einer Klasse
* Deklarationsbereich einer Testmethode
* Erweiterung des Row-Attributs

== AccUnit:ClickingMsgBox ==

Mausklicks für Msgbox-Ersatzfunktion

==== Syntax ====
<source>' AccUnit:ClickingMsgBox(vbYes, vbOk, vbNo)</source>

==== Verwendbar in ====
* Deklarationsbereich einer Testmethode
* Erweiterung des Row-Attributs

AccUnit-Attribute

Josef Pötzl — Fri, 11 Mar 2011 16:46:55 GMT

Josef Pötzl: Die Seite wurde neu angelegt: „__NOTOC__ == AccUnit:TestClass == Markiert eine Klasse als Testklasse. ==== Syntax ==== <source>' AccUnit:TestClass</source> ==== Verwendbar in ==== * Deklaratio…“

__NOTOC__
== AccUnit:TestClass ==
Markiert eine Klasse als Testklasse.
==== Syntax ====
<source>' AccUnit:TestClass</source>

==== Verwendbar in ====
* Deklarationsbereich einer Klasse

== AccUnit:TestRelated ==
Markiert eine Klasse oder ein Standardmodul als Hilfsmodulen für Tests. Diese Codemodule bzw. Formulare/Berichte können wie die Testklassen importiert bzw. exportiert werden.
==== Syntax ====
<source>' AccUnit:TestRelated </source>

==== Verwendbar in ====
* Deklarationsbereich einer Klasse
* Deklarationsbereich eines Standardmoduls
* Deklarationsbereich eines Formular- oder Bericht-Moduls

== AccUnit:Row ==
==== Syntax ====
<source>' AccUnit:Row(Param1, Param2)</source>

==== Verwendbar in ====
* Deklarationsbereich einer Testmethode

== AccUnit:Tags ==
==== Syntax ====
<source>' AccUnit:Tags(Tag1, Tag2, Tag3)</source>

==== Verwendbar in ====
* Deklarationsbereich einer Testklasse
* Deklarationsbereich einer Testmethode
* Erweiterung des Row-Attributs

== AccUnit:Ignore ==
==== Syntax ====
<source>' AccUnit:Ignore(Comment)</source>

==== Verwendbar in ====
* Deklarationsbereich einer Klasse
* Deklarationsbereich einer Testmethode
* Erweiterung des Row-Attributs

== AccUnit:ClickingMsgBox ==
==== Syntax ====
<source>' AccUnit:ClickingMsgBox(vbYes, vbOk, vbNo)</source>

==== Verwendbar in ====
* Deklarationsbereich einer Testmethode
* Erweiterung des Row-Attributs

Grundlagen

Josef Pötzl — Fri, 11 Mar 2011 16:27:02 GMT

Josef Pötzl:

Installation

Josef Pötzl — Sat, 05 Mar 2011 15:50:59 GMT

Josef Pötzl:

__NOTOC__ [[en:Installation]]

Für die Verwendung von AccUnit muss [[SimplyVBUnit|SimplyVBUnit 3.0]] installiert sein.
SimplyVBUnit ist ein in Visual Basic 6 geschriebenes Testframework.
Weitere Informationen zu VBUnit finden Sie auf
der [http://sourceforge.net/projects/simplyvbunit/ Projektseite von SimplyVBUnit auf sourceforge].

Laden Sie die Setup-Datei, die Sie ist unter ''[http://sourceforge.net/projects/simplyvbunit/files/ View all files]'' finden.

AccUnit verursacht (derzeit noch) Probleme bei der Verwendung unter Access 2000.

Danach können Sie von dieser Webseite das AccUnit Programm [http://accunit.access-codelib.net/download/AccUnitSetup.zip AccUnitSetup.zip]
laden und die Installation mit ''Setup.exe'' starten.

=== AccUnit als VBE-Add-In verwenden ===
AccUnit installiert sich als VBE AddIn im Visual Basic Editor.
Sie finden AccUnit einmal als Menüpunkt unter Extras->AccUnit
und zweitens als zusätzlich Symbolleiste mit vier Symbolen.

[[Bild:AccUnit-Menue.jpg]]

[[Bild:AccUnit-Symbole.jpg]]

Installation

Josef Pötzl — Sat, 05 Mar 2011 15:50:44 GMT

Josef Pötzl:

__NOTOC__ [[en:Installation]]

Für die Verwendung von AccUnit muss [[SimplyVBUnit|SimplyVBUnit 3.0]] installiert sein.
SimplyVBUnit ist ein in Visual Basic 6 geschriebenes Testframework.
Weitere Informationen zu VBUnit finden Sie auf
der [http://sourceforge.net/projects/simplyvbunit/ Projektseite von SimplyVBUnit auf sourceforge].

Laden Sie die Setup-Datei, die Sie ist unter ''[http://sourceforge.net/projects/simplyvbunit/files/ View all files]'' finden.

AccUnit verursacht (derzeit) noch Probleme bei der Verwendung unter Access 2000.

Danach können Sie von dieser Webseite das AccUnit Programm [http://accunit.access-codelib.net/download/AccUnitSetup.zip AccUnitSetup.zip]
laden und die Installation mit ''Setup.exe'' starten.

=== AccUnit als VBE-Add-In verwenden ===
AccUnit installiert sich als VBE AddIn im Visual Basic Editor.
Sie finden AccUnit einmal als Menüpunkt unter Extras->AccUnit
und zweitens als zusätzlich Symbolleiste mit vier Symbolen.

[[Bild:AccUnit-Menue.jpg]]

[[Bild:AccUnit-Symbole.jpg]]

Grundlagen

Josef Pötzl — Fri, 25 Feb 2011 13:09:19 GMT

Josef Pötzl:

[[en:Basics]]
Eine Software zu testen bedeutet, festzustellen, ob die Software an sie gestellte Anforderungen auch erfüllt.

Anforderungen in Umgangssprache sind jedoch nicht geeignet als Grundlage eines Tests.
( "Naja, das Ding soll halt nicht abstürzen" oder "Wenn ich da vorne 100 eingeben, dann soll da hinten irgendwas rauskommen.. " )

Zudem ist es nicht möglich komplexe Applikationen präzise zu beschreiben.

Zum Testen von Software ist es also wichtig, die große Komplexität einer Applikation in kleine testbare Programmstückchen aufzuteilen.
Diese Programmstückchen sollten dann EINE Aufgabe erledigen, so daß man diese Programmstückchen testet in dem man beschreibt:

- welches Programmstück ( Modul, Klasse, Funktion, Sub ) teste ich
- welche Eingabewerte ( Vorbedingungen ) erhält das Programmstück
- welche Ausgabewerte ( Nachbedingungen ) erwarte ich

Unter Umständen wird es also nötig sein den bestehenden Programmcode zu überarbeiten und in kleine testbare Einheiten zu zerlegen.

== Der erste Test ==

Den ersten Test wollen wir natürlich nicht mit einem komplexen sondern mit einem ganz simplen Beispiel beginnen:
Es soll eine Funktion erstellt werden, die zu einem Dezimal Wert die binäre Darstellung liefert.

Ein entsprechende VBA Funktion könnte also so aussehen:
<source>Public Function Dez2Bin(ByVal TheValue As Long) As String</source>

Wie könnte also der erste Test lauten ?
- Die Funktion Dez2Bin
- liefert bei einer Eingabe des Dezimalwerts 0
- einen String mit der Ziffer "0"

Erstellen Sie also ein neues Modul mit dem oben genannten Funktionsrumpf. Klicken Sie innerhalb dieser Funktion die rechte Maustaste und wählen Sie "Neue Testmethode einfügen". [[Bild: AccUnit_Test1.jpg]]

es öffnet sich der Dialog zum Einfügen einer neue Testmethode:
[[Bild: AccUnit-DialogEinfuegen.jpg]]

AccUnit wird zu unserem Modul mit den zu testenden Funktionen eine neue Testklasse erstellen, in denen dann die Testmethoden untergebracht sind. Das Modul mit der Funktion Dez2Bin habe ich "Umrechungen" genannt. AccUnit schlägt als Name für die Testklasse "UmrechnungeTest" vor, den Sie so übernehmen sollten. Bei den zu testenden Methode ist schon unsere Funktion De2Bin ausgewählt, so daß wir nur noch den zu testenden Zustand und das erwartete Verhalten eintragen müssen.
Als zu testender Zustand tragen wir ein: "mitEingabe0"
und als erwartetes Verhalten: "liefertdenString0"
AccUnit erzeugt aus diesen beiden Angaben den Namen der Testmethode. Achten Sie also darauf, daß Sie keine Leerzeichen, Anführungszeichen oder andere Sonderzeichen verwenden, die in Methodennamen nicht erlaubt sind.

AccUnit erzeugt die die Testklasse:
<source>
Option Compare Text
Option Explicit
'AccUnit:TestClass
'--------------------------------------------------------------------
' AccUnit Infrastructure
'--------------------------------------------------------------------
Implements SimplyVBUnit.ITestFixture
Implements AccUnit_Integration.ITestManagerBridge
Private TestManager As AccUnit_Integration.TestManager
Private Sub ITestManagerBridge_InitTestManager(ByVal NewTestManager As AccUnit_Integration.ITestManagerComInterface): Set TestManager = NewTestManager: End Sub
Private Function ITestManagerBridge_GetTestManager() As AccUnit_Integration.ITestManagerComInterface: Set ITestManagerBridge_GetTestManager = TestManager: End Function
Private Sub ITestFixture_AddTestCases(ByVal Tests As SimplyVBUnit.TestCaseCollector): TestManager.AddTestCases Tests: End Sub
'--------------------------------------------------------------------
' Tests
'--------------------------------------------------------------------
'
Public Sub Dez2Bin_mitEingabe0_liefertdenString0()
' Arrange
Err.Raise vbObjectError, "Dez2Bin_mitEingabe0_liefertdenString0", "Not implemented"
' Act
' Assert
Assert.That 1, Iz.EqualTo(1)
End Sub
</source>

In dem Bereich 'AccUnit Infrastructure' werden ein paar Funktionen definiert die von der Testumgebung benötigt werden.
Bitte nehmen Sie in diesem Bereich KEINE Änderungen vor.

Grundlagen

Josef Pötzl — Fri, 25 Feb 2011 13:01:14 GMT

Josef Pötzl: Source-Tag ergänzt

Eine Software zu testen bedeutet, festzustellen, ob die Software an sie gestellte Anforderungen auch erfüllt.

Anforderungen in Umgangssprache sind jedoch nicht geeignet als Grundlage eines Tests.
( "Naja, das Ding soll halt nicht abstürzen" oder "Wenn ich da vorne 100 eingeben, dann soll da hinten irgendwas rauskommen.. " )

Zudem ist es nicht möglich komplexe Applikationen präzise zu beschreiben.

Zum Testen von Software ist es also wichtig, die große Komplexität einer Applikation in kleine testbare Programmstückchen aufzuteilen.
Diese Programmstückchen sollten dann EINE Aufgabe erledigen, so daß man diese Programmstückchen testet in dem man beschreibt:

- welches Programmstück ( Modul, Klasse, Funktion, Sub ) teste ich
- welche Eingabewerte ( Vorbedingungen ) erhält das Programmstück
- welche Ausgabewerte ( Nachbedingungen ) erwarte ich

Unter Umständen wird es also nötig sein den bestehenden Programmcode zu überarbeiten und in kleine testbare Einheiten zu zerlegen.

== Der erste Test ==

Den ersten Test wollen wir natürlich nicht mit einem komplexen sondern mit einem ganz simplen Beispiel beginnen:
Es soll eine Funktion erstellt werden, die zu einem Dezimal Wert die binäre Darstellung liefert.

Ein entsprechende VBA Funktion könnte also so aussehen:
<source>Public Function Dez2Bin(ByVal TheValue As Long) As String</source>

Wie könnte also der erste Test lauten ?
- Die Funktion Dez2Bin
- liefert bei einer Eingabe des Dezimalwerts 0
- einen String mit der Ziffer "0"

Erstellen Sie also ein neues Modul mit dem oben genannten Funktionsrumpf. Klicken Sie innerhalb dieser Funktion die rechte Maustaste und wählen Sie "Neue Testmethode einfügen". [[Bild: AccUnit_Test1.jpg]]

es öffnet sich der Dialog zum Einfügen einer neue Testmethode:
[[Bild: AccUnit-DialogEinfuegen.jpg]]

AccUnit wird zu unserem Modul mit den zu testenden Funktionen eine neue Testklasse erstellen, in denen dann die Testmethoden untergebracht sind. Das Modul mit der Funktion Dez2Bin habe ich "Umrechungen" genannt. AccUnit schlägt als Name für die Testklasse "UmrechnungeTest" vor, den Sie so übernehmen sollten. Bei den zu testenden Methode ist schon unsere Funktion De2Bin ausgewählt, so daß wir nur noch den zu testenden Zustand und das erwartete Verhalten eintragen müssen.
Als zu testender Zustand tragen wir ein: "mitEingabe0"
und als erwartetes Verhalten: "liefertdenString0"
AccUnit erzeugt aus diesen beiden Angaben den Namen der Testmethode. Achten Sie also darauf, daß Sie keine Leerzeichen, Anführungszeichen oder andere Sonderzeichen verwenden, die in Methodennamen nicht erlaubt sind.

AccUnit erzeugt die die Testklasse:
<source>
Option Compare Text
Option Explicit
'AccUnit:TestClass
'--------------------------------------------------------------------
' AccUnit Infrastructure
'--------------------------------------------------------------------
Implements SimplyVBUnit.ITestFixture
Implements AccUnit_Integration.ITestManagerBridge
Private TestManager As AccUnit_Integration.TestManager
Private Sub ITestManagerBridge_InitTestManager(ByVal NewTestManager As AccUnit_Integration.ITestManagerComInterface): Set TestManager = NewTestManager: End Sub
Private Function ITestManagerBridge_GetTestManager() As AccUnit_Integration.ITestManagerComInterface: Set ITestManagerBridge_GetTestManager = TestManager: End Function
Private Sub ITestFixture_AddTestCases(ByVal Tests As SimplyVBUnit.TestCaseCollector): TestManager.AddTestCases Tests: End Sub
'--------------------------------------------------------------------
' Tests
'--------------------------------------------------------------------
'
Public Sub Dez2Bin_mitEingabe0_liefertdenString0()
' Arrange
Err.Raise vbObjectError, "Dez2Bin_mitEingabe0_liefertdenString0", "Not implemented"
' Act
' Assert
Assert.That 1, Iz.EqualTo(1)
End Sub
</source>

In dem Bereich 'AccUnit Infrastructure' werden ein paar Funktionen definiert die von der Testumgebung benötigt werden.
Bitte nehmen Sie in diesem Bereich KEINE Änderungen vor.

Grundlagen

Josef Pötzl — Fri, 25 Feb 2011 12:58:18 GMT

Josef Pötzl: Source-Tag ergänzt

Eine Software zu testen bedeutet, festzustellen, ob die Software an sie gestellte Anforderungen auch erfüllt.

Anforderungen in Umgangssprache sind jedoch nicht geeignet als Grundlage eines Tests.
( "Naja, das Ding soll halt nicht abstürzen" oder "Wenn ich da vorne 100 eingeben, dann soll da hinten irgendwas rauskommen.. " )

Zudem ist es nicht möglich komplexe Applikationen präzise zu beschreiben.

Zum Testen von Software ist es also wichtig, die große Komplexität einer Applikation in kleine testbare Programmstückchen aufzuteilen.
Diese Programmstückchen sollten dann EINE Aufgabe erledigen, so daß man diese Programmstückchen testet in dem man beschreibt:

- welches Programmstück ( Modul, Klasse, Funktion, Sub ) teste ich
- welche Eingabewerte ( Vorbedingungen ) erhält das Programmstück
- welche Ausgabewerte ( Nachbedingungen ) erwarte ich

Unter Umständen wird es also nötig sein den bestehenden Programmcode zu überarbeiten und in kleine testbare Einheiten zu zerlegen.

== Der erste Test ==

Den ersten Test wollen wir natürlich nicht mit einem komplexen sondern mit einem ganz simplen Beispiel beginnen:
Es soll eine Funktion erstellt werden, die zu einem Dezimal Wert die binäre Darstellung liefert.

Ein entsprechende VBA Funktion könnte also so aussehen:
Public Function Dez2Bin(ByVal TheValue As Long) As String

Wie könnte also der erste Test lauten ?
- Die Funktion Dez2Bin
- liefert bei einer Eingabe des Dezimalwerts 0
- einen String mit der Ziffer "0"

Erstellen Sie also ein neues Modul mit dem oben genannten Funktionsrumpf. Klicken Sie innerhalb dieser Funktion die rechte Maustaste und wählen Sie "Neue Testmethode einfügen". [[Bild: AccUnit_Test1.jpg]]

es öffnet sich der Dialog zum Einfügen einer neue Testmethode:
[[Bild: AccUnit-DialogEinfuegen.jpg]]

AccUnit wird zu unserem Modul mit den zu testenden Funktionen eine neue Testklasse erstellen, in denen dann die Testmethoden untergebracht sind. Das Modul mit der Funktion Dez2Bin habe ich "Umrechungen" genannt. AccUnit schlägt als Name für die Testklasse "UmrechnungeTest" vor, den Sie so übernehmen sollten. Bei den zu testenden Methode ist schon unsere Funktion De2Bin ausgewählt, so daß wir nur noch den zu testenden Zustand und das erwartete Verhalten eintragen müssen.
Als zu testender Zustand tragen wir ein: "mitEingabe0"
und als erwartetes Verhalten: "liefertdenString0"
AccUnit erzeugt aus diesen beiden Angaben den Namen der Testmethode. Achten Sie also darauf, daß Sie keine Leerzeichen, Anführungszeichen oder andere Sonderzeichen verwenden, die in Methodennamen nicht erlaubt sind.

AccUnit erzeugt die die Testklasse:
<source>
Option Compare Text
Option Explicit
'AccUnit:TestClass
'--------------------------------------------------------------------
' AccUnit Infrastructure
'--------------------------------------------------------------------
Implements SimplyVBUnit.ITestFixture
Implements AccUnit_Integration.ITestManagerBridge
Private TestManager As AccUnit_Integration.TestManager
Private Sub ITestManagerBridge_InitTestManager(ByVal NewTestManager As AccUnit_Integration.ITestManagerComInterface): Set TestManager = NewTestManager: End Sub
Private Function ITestManagerBridge_GetTestManager() As AccUnit_Integration.ITestManagerComInterface: Set ITestManagerBridge_GetTestManager = TestManager: End Function
Private Sub ITestFixture_AddTestCases(ByVal Tests As SimplyVBUnit.TestCaseCollector): TestManager.AddTestCases Tests: End Sub
'--------------------------------------------------------------------
' Tests
'--------------------------------------------------------------------
'
Public Sub Dez2Bin_mitEingabe0_liefertdenString0()
' Arrange
Err.Raise vbObjectError, "Dez2Bin_mitEingabe0_liefertdenString0", "Not implemented"
' Act
' Assert
Assert.That 1, Iz.EqualTo(1)
End Sub
</source>

In dem Bereich 'AccUnit Infrastructure' werden ein paar Funktionen definiert die von der Testumgebung benötigt werden.
Bitte nehmen Sie in diesem Bereich KEINE Änderungen vor.

Installation

Josef Pötzl — Tue, 15 Feb 2011 08:29:14 GMT

Josef Pötzl:

__NOTOC__ [[en:Installation]]
Download: [http://accunit.access-codelib.net/download/AccUnitSetup.zip AccUnitSetup.zip]
Die Installation mit ''Setup.exe'' starten.

Für die Verwendung von AccUnit muss [[SimplyVBUnit|SimplyVBUnit 3.0]] installiert sein.
Die Setup-Datei ist unter ''[http://sourceforge.net/projects/simplyvbunit/files/ View all files]'' der [http://sourceforge.net/projects/simplyvbunit/ Projektseite von SimplyVBUnit auf sourceforge] verfügbar.

=== AccUnit als VBE-Add-In verwenden ===
Wenn Sie das VBE-Add-In nutzen, könnten Sie AccUnit über das Menü des VBA-Editor bedienen.

=== Nutzung ohne Add-In ===
''(wird nicht empfohlen)''

Die folgenden Punkte sind für die Bedienung per Add-In nicht erforderlich.
==== AccUnit-Unterstützung für Debug-Fenster ====
===== Konfiguration der Access-Anwendungen =====
====== aktivieren ======
Eingabe im Direktfenster: <code>CreateObject("AccUnit.Configurator").Init VBE.ActiveVBProject</code>

Ergebnis:
* Verweise auf AccUnit und SimplyVBUnit werden gesetzt
* Hilfsklasse ''TestSuiteStarter'' und das Modul ''_AccUnitObjects'' werden eingefügt

====== entfernen ======
Eingabe im Direktfenster: <code>CreateObject("AccUnit.Configurator").Remove VBE.ActiveVBProject</code>

MediaWiki:Sidebar

Josef Pötzl — Mon, 14 Feb 2011 10:52:30 GMT

Josef Pötzl:

MediaWiki:Sidebar

Josef Pötzl — Mon, 14 Feb 2011 10:52:19 GMT

Josef Pötzl:

MediaWiki:Sidebar

Josef Pötzl — Mon, 14 Feb 2011 10:50:02 GMT

Josef Pötzl: