AccUnit - User contributions [en]

Getting started

Josef Pötzl — Mon, 26 Aug 2024 21:55:22 GMT

Josef Pötzl:

[[de:Erste_Schritte]]

[http://en.wikipedia.org/wiki/Software_testing Software testing] is a important part of software development.

In earlier days testing of a software was typically done at the end of the development cycle.
Since this is very late to uncover severe problems, today's approach relies heavily on test automation. An important part for this is testing individual pieces of the code (unit testing). Even more, with [http://en.wikipedia.org/wiki/Test-driven_development Test-Driven-Development (TDD)] tests are written before implementing a part of the application.

Many actual programming languages provide appropriate tools for automated test execution. The [http://en.wikipedia.org/wiki/Visual_Basic_for_Applications VBA] programming language and the Code Editor (the VBE - Visual Basic Editor)
unfortunately only contain rudimentary functionality to support testing of code (Debug.Print, Debug.Assert).

'''AccUnit''' now offers the possibility to run automated tests on MS Access.

The following pages will help you to write the first tests for your application.

User Interface

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

Josef Pötzl:

[[de:Benutzeroberfläche]] __NOTOC__

Is this user interface needed in the new version, or is the output to the direct area sufficient?

[[Image:AccUnit_VBE.png]]

==== Toolbar ====

[[Image:AccUnit_AddIn_Commandbar_Beschreibung.png]]

==== Menu items ====

[[Image:AccUnit_AddIn_Menu_Tools.png]]
[[Image:AccUnit_AddIn_Menu_View.png]]

==== VBE-Windows ====
[[Image:AccUnit_AddIn_Testauswahl.png]]

[[Image:AccUnit_AddIn_Testergebnis.png]]

==== Dialogs ====
[[Image:AccUnit_AddIn_TestImport.png]]
[[Image:AccUnit_AddIn_TestExport.png]]

[[Image:AccUnit_AddIn_UserSettings.png]]

[[Shortcuts]]

Installation

Josef Pötzl — Wed, 09 Aug 2023 17:28:59 GMT

Josef Pötzl:

[[de:Installation]]

AccUnit uses the Access add-in AccUnitLoader. Only this access add-in needs to be installed.

Installation procedure see [https://github.com/AccessCodeLib/AccUnit/wiki/How-to:-Install-AccUnit GitHub wiki].

Installation

Josef Pötzl — Mon, 04 May 2015 16:45:20 GMT

Josef Pötzl:

[[de:Installation]]

[[Supported Platforms]]

[[Prerequisites]]

Before using AccUnit you have to install SimplyVBUnit 3.0 ([http://sourceforge.net/projects/simplyvbunit/ project page of SimplyVBUnit at sourceforge]).

You will find the setup file here: ''[http://accunit.access-codelib.net/download/SimplyVBUnitSetup.zip SimplyVBUnitSetup.zip]''.

'''''*** IMPORTANT ***'''''
As of November 2012, on the SimplyVBUnit's project site, there is the version v4 of SimplyVBUnit available. That version is '''not compatible''' with AccUnit. Thus, make sure to use the link to SimplyVBUnit 3.0 provided above.

You may start the download of AccUnit here: [http://accunit.access-codelib.net/download/AccUnitSetup.zip AccUnitSetup.zip]
Start you installation with ''Setup.exe''.

=== AccUnit as VBE-Add-In ===

AccUnit

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

Josef Pötzl:

[[Conceptual]]

[[Known Issues]]

[[de:AccUnit]]

AccUnit

Josef Pötzl — Mon, 04 Nov 2013 08:32:22 GMT

Josef Pötzl:

[[Conceptual]]

[[Known Issues]]

[[fr:AccUnit]]
[[de:AccUnit]]

AccUnit

Josef Pötzl — Mon, 04 Nov 2013 08:24:15 GMT

Josef Pötzl:

[[Conceptual]]

[[Known Issues]]

[[:fr:AccUnit]]
[[de:AccUnit]]

AccUnit

Josef Pötzl — Mon, 04 Nov 2013 08:23:56 GMT

Josef Pötzl:

[[Conceptual]]

[[Known Issues]]

[[:fr:AccUnit]]
[[:de:AccUnit]]

AccUnit

Josef Pötzl — Mon, 04 Nov 2013 08:20:58 GMT

Josef Pötzl:

[[Conceptual]]

[[Known Issues]]

[[fr:AccUnit]]
[[de:AccUnit]]

NewTestRunner

Josef Pötzl — Sun, 15 Jan 2012 13:42:45 GMT

Josef Pötzl: /* Data structures */

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

[[image: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 ... message + status of rows?)
** StartedAt
** EndedAt

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

Notes

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

Josef Pötzl:

[[de:Notizen]]

[[NewTestRunner|New TestRunner]]

NewTestRunner

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

Josef Pötzl:

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

[[image: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:52:31 GMT

Josef Pötzl:

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

[[File: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:50:53 GMT

Josef Pötzl:

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

== 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:50:36 GMT

Josef Pötzl: Created page with 'de:NewTestRunner This is a first draft for an AccUnit TestRunner. 480px == Details == (Gathered mainly as results of the discussion…'

[[de: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

Installation

Josef Pötzl — Thu, 22 Dec 2011 12:50:42 GMT

Josef Pötzl:

[[de:Installation]]

Before using AccUnit you have to install SimplyVBUnit 3.0.

You will find the setup file here: ''[http://sourceforge.net/projects/simplyvbunit/files/ View all files]'' on the [http://sourceforge.net/projects/simplyvbunit/ project page of SimplyVBUnit at sourceforge].

You may start the download of AccUnit here: [http://accunit.access-codelib.net/download/AccUnitSetup.zip AccUnitSetup.zip]
Start you installation with ''Setup.exe''.

=== AccUnit as VBE-Add-In ===

Basics

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

Josef Pötzl: Created page with 'de:Grundlagen'

[[de:Grundlagen]]

Advanced features

Josef Pötzl — Sat, 12 Feb 2011 20:29:31 GMT

Josef Pötzl:

[[de:Erweiterte_Funktionen]]

[[Testing with vbWatchdog]]

Advanced features

Josef Pötzl — Sat, 12 Feb 2011 20:29:20 GMT

Josef Pötzl:

[[de:Erweiterte_Funktionen]]

[Testing with vbWatchdog]

Testing with vbWatchdog

Josef Pötzl — Sat, 12 Feb 2011 20:27:58 GMT

Josef Pötzl:

[[de:Testen mit vbWatchdog]]
Use <code>PropagateUnhandledClassErrors</code> to configure vbWatchdog (Version 2.3.2 or higher) for testing in Setup/TearDown.
<source>
Public Sub Setup()
EnableWatchdog
ErrEx.PropagateUnhandledClassErrors = True
End Sub

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

Testing with vbWatchdog

Josef Pötzl — Sat, 12 Feb 2011 20:27:36 GMT

Josef Pötzl:

[[de:Testen mit vbWatchdog]]
Use PropagateUnhandledClassErrors to configure vbWatchdog (Version 2.3.2 or higher) for testing in Setup/TearDown.
<source>
Public Sub Setup()
EnableWatchdog
ErrEx.PropagateUnhandledClassErrors = True
End Sub

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

Testing with vbWatchdog

Josef Pötzl — Sat, 12 Feb 2011 20:14:36 GMT

Josef Pötzl: Created page with 'de:Testen mit vbWatchdog <source> Public Sub Setup() EnableWatchdog ErrEx.PropagateUnhandledClassErrors = True End Sub Public Sub TearDown() DisableWatchdog Err…'

[[de:Testen mit vbWatchdog]]

<source>
Public Sub Setup()
EnableWatchdog
ErrEx.PropagateUnhandledClassErrors = True
End Sub

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

Advanced features

Josef Pötzl — Sat, 12 Feb 2011 20:11:25 GMT

Josef Pötzl: Created page with 'de:Erweiterte_Funktionen'

[[de:Erweiterte_Funktionen]]

MediaWiki:Sidebar

Josef Pötzl — Tue, 08 Feb 2011 08:11:32 GMT

Josef Pötzl:

MediaWiki:Sidebar

Josef Pötzl — Tue, 08 Feb 2011 08:10:46 GMT

Josef Pötzl:

MediaWiki:Advancedfeatures-description

Josef Pötzl — Mon, 07 Feb 2011 19:36:27 GMT

Josef Pötzl:

Advanced features

MediaWiki:Advancedfeatures-url

Josef Pötzl — Mon, 07 Feb 2011 19:36:09 GMT

Josef Pötzl:

Advanced features

MediaWiki:Basics-description/de

Josef Pötzl — Mon, 07 Feb 2011 19:33:12 GMT

Josef Pötzl: Created page with 'Grundlagen'

Grundlagen

MediaWiki:Basics-description

Josef Pötzl — Mon, 07 Feb 2011 19:33:00 GMT

Josef Pötzl: Created page with 'Basics'

Basics

MediaWiki:Tips-description/de

Josef Pötzl — Mon, 07 Feb 2011 19:28:50 GMT

Josef Pötzl: Created page with 'Tipps und Tricks'

Tipps und Tricks

MediaWiki:Tips-description

Josef Pötzl — Mon, 07 Feb 2011 19:28:23 GMT

Josef Pötzl: Created page with 'Tips and tricks'

Tips and tricks

MediaWiki:Tips-url

Josef Pötzl — Mon, 07 Feb 2011 19:27:27 GMT

Josef Pötzl: Created page with 'Tips and tricks'

Tips and tricks

MediaWiki:Advancedfeatures-description/de

Josef Pötzl — Mon, 07 Feb 2011 19:24:07 GMT

Josef Pötzl: moved MediaWiki:Advancedfeatures-description/en to MediaWiki:Advancedfeatures-description/de

Erweiterte Funktionen

MediaWiki:Advancedfeatures-description/de

Josef Pötzl — Mon, 07 Feb 2011 19:23:21 GMT

Josef Pötzl: Created page with 'Erweiterte Funktionen'

Erweiterte Funktionen

MediaWiki:Advancedfeatures-description

Josef Pötzl — Mon, 07 Feb 2011 19:22:54 GMT

Josef Pötzl: Created page with 'Advanced Features'

Advanced Features

MediaWiki:Advancedfeatures-url

Josef Pötzl — Mon, 07 Feb 2011 19:22:39 GMT

Josef Pötzl: Created page with 'Advanced Features'

Advanced Features

MediaWiki:Basics-url

Josef Pötzl — Mon, 07 Feb 2011 19:21:27 GMT

Josef Pötzl: Created page with 'Basics'

Basics

MediaWiki:Sidebar

Josef Pötzl — Mon, 07 Feb 2011 19:20:20 GMT

Josef Pötzl:

MediaWiki:Userinterface-description/de

Josef Pötzl — Sun, 06 Feb 2011 18:39:38 GMT

Josef Pötzl: Created page with 'Benutzeroberfläche'

Benutzeroberfläche

User Interface

Josef Pötzl — Sun, 06 Feb 2011 18:35:59 GMT

Josef Pötzl:

[[de:Benutzeroberfläche]] __NOTOC__
[[Image:AccUnit_VBE.png]]

==== Symbolleiste ====

[[Image:AccUnit_AddIn_Commandbar_Beschreibung.png]]

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

[[Image:AccUnit_AddIn_Menu_Tools.png]]
[[Image:AccUnit_AddIn_Menu_View.png]]

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

[[Image:AccUnit_AddIn_Testergebnis.png]]

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

[[Image:AccUnit_AddIn_UserSettings.png]]

MediaWiki:Userinterface-url

Josef Pötzl — Sun, 06 Feb 2011 18:35:07 GMT

Josef Pötzl: Created page with 'User Interface'

User Interface

MediaWiki:Userinterface-description

Josef Pötzl — Sun, 06 Feb 2011 18:34:52 GMT

Josef Pötzl: Created page with 'User Interface'

User Interface

MediaWiki:Sidebar

Josef Pötzl — Sun, 06 Feb 2011 18:34:38 GMT

Josef Pötzl:

User Interface

Josef Pötzl — Sun, 06 Feb 2011 18:33:33 GMT

Josef Pötzl: moved VBE Add-in to User Interface

[[de:VBE-Add-In]] __NOTOC__
[[Image:AccUnit_VBE.png]]

==== Symbolleiste ====

[[Image:AccUnit_AddIn_Commandbar_Beschreibung.png]]

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

[[Image:AccUnit_AddIn_Menu_Tools.png]]
[[Image:AccUnit_AddIn_Menu_View.png]]

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

[[Image:AccUnit_AddIn_Testergebnis.png]]

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

[[Image:AccUnit_AddIn_UserSettings.png]]

Template:Email

Josef Pötzl — Sun, 06 Feb 2011 17:19:47 GMT

Josef Pötzl: Protected "Template:Email" ([edit=sysop] (indefinite) [move=sysop] (indefinite))

<onlyinclude>{{{1}}}</onlyinclude><noinclude>

Beispiel: {{email|access.joposol.com}}

[[Category:Template:Symbol]]
</noinclude>

Template:Phonenumber

Josef Pötzl — Sun, 06 Feb 2011 17:19:37 GMT

Josef Pötzl: Protected "Template:Phonenumber" ([edit=sysop] (indefinite) [move=sysop] (indefinite))

<onlyinclude>{{{1}}}</onlyinclude><noinclude>

Beispiel: {{phonenumber|12 34 56}}

[[Category:Template:Symbol]]
</noinclude>

Template:Faxnumber

Josef Pötzl — Sun, 06 Feb 2011 17:19:23 GMT

Josef Pötzl: Protected "Template:Faxnumber" ([edit=sysop] (indefinite) [move=sysop] (indefinite))

<onlyinclude>{{{1}}}</onlyinclude><noinclude>

Beispiel: {{faxnumber|12 34 56}}

[[Category:Template:Symbol]]
</noinclude>

AccUnit:Impressum

Josef Pötzl — Sun, 06 Feb 2011 17:19:03 GMT

Josef Pötzl: Protected "AccUnit:Impressum" ([edit=sysop] (indefinite) [move=sysop] (indefinite))

----
{| border="0" cellpadding="2"
|-valign="top"
|Name:
|Josef Pötzl
|-valign="top"
|Adresse:
|Idlhofgasse 22a/21 8020 Graz Österreich
|-valign="top"
|Kontaktdaten:
|{{email|josef.poetzl@joposol.com}} {{phonenumber|+43 (316) 21 40 56 bzw. +43 (699) 19 21 40 56}} {{faxnumber|+43 (316) 21 40 56}}
|-valign="top"
|Kammerzugehörigkeit:
|[http://portal.wko.at/ Wirtschaftskammer Steiermark] [http://www.ubit.at/ Fachgruppe Unternehmensberatung und Informationstechnologie]
|-valign="top"
|UID-Nummer:
|ATU60084358
|-valign="top"
|Geschäftsleitung:
|Dipl.-Ing. Josef Pötzl
|}
----
[http://firmena-z.wko.at/ecg.asp?MGID=69031981F5BC249103981298C2B33455 Informationspflicht lt. § 5 Abs. 1 E-Commerce-Gesetz und Offenlegungspflicht gemäß Mediengesetz §25]

Template:Faxnumber

Josef Pötzl — Sun, 06 Feb 2011 17:16:40 GMT

Josef Pötzl: Created page with '<onlyinclude>{{{1}}}</onlyinclude><noinclude> Beispiel: {{faxnumber|12 34 56}} Category:Template:Symbol </noinclude>'

<onlyinclude>{{{1}}}</onlyinclude><noinclude>

Beispiel: {{faxnumber|12 34 56}}

[[Category:Template:Symbol]]
</noinclude>

Template:Phonenumber

Josef Pötzl — Sun, 06 Feb 2011 17:16:12 GMT

Josef Pötzl: Created page with '<onlyinclude>{{{1}}}</onlyinclude><noinclude> Beispiel: {{phonenumber|12 34 56}} Category:Template:Symbol </noinclude>'

<onlyinclude>{{{1}}}</onlyinclude><noinclude>

Beispiel: {{phonenumber|12 34 56}}

[[Category:Template:Symbol]]
</noinclude>

Template:Email

Josef Pötzl — Sun, 06 Feb 2011 17:14:22 GMT

Josef Pötzl:

<onlyinclude>{{{1}}}</onlyinclude><noinclude>

Beispiel: {{email|access.joposol.com}}

[[Category:Template:Symbol]]
</noinclude>