Schnittstelle für Zugriff aus "fremden" Add-Ins o. ä.

Testen von Access-Anwendungen

Schnittstelle für Zugriff aus "fremden" Add-Ins o. ä.

Beitragvon Josef Pötzl » Di 28. Sep 2010, 23:38

Hallo!

Während der AEK wurde nachgefragt, ob es eine Möglichkeit gibt, AccUnit fernzusteuern (z. B. Starten des Testablaufs durch ein anderes Add-In und Rückgabe des Testergebnisses).
Diese Funktionaltität ist im Prinzip bereits vorhanden, da das AccUnit.Integration-Assembly ebenfalls vom Add-In-Assembly gesteuert wird.
Vermutlich wäre es aber praktischer, wenn wir die benötigten Funktionalitäten in einem extra Interface (natürlich COM-sichtbar) unterbringen, falls ITestSuite bzw. IAccessTestSuite nicht ausreichen.

Grob zusammengefasst:
Die Teststeuerung von AccUnit übernimmt eine ITestSuite. Sobald Access verwendet wird, kommt die AccessTestSuite zum Einsatz (bei Excel oder Word wäre das VBATestSuite).
Das Add-In wird über die Klasse AddInManager gesteuert. Für diese Klasse gibt es eine extra Hilfsklasse (AddInManagerBridge) für den Add-In-Zugriff von der Hostanwendung. Man könnte also auch an dieser Stelle mit einem "fremden" Add-In einsteigen, falls z. B. die Ausgabefenster benötigt werden.

Ich schlage vor, dass wir in diesem Thread versuchen, die erforderlichen Schnittstellen zu beschreiben. :)

mfg
Josef
Josef Pötzl
Moderator
 
Beiträge: 717
Registriert: Mo 30. Nov 2009, 11:08
Wohnort: Klagenfurt
Accessversion: 2010 (2013)

Re: Schnittstelle für Zugriff aus "fremden" Add-Ins o. ä.

Beitragvon Bernd Gilles » Mi 29. Sep 2010, 00:16

Das angedachte
Summary = AccessTestSuiteReferenz.AddFromVBProject.Run.Summary

Würde mir persönlich für's Erste vollkommen ausreichen.

Der folgende Beispielcode liefert aber Fehler -2147467261 ("Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt").

Code: Alles auswählen
Public Sub RunAllTests()
Dim TestSuite As AccessTestSuite
Dim Summary As ITestSummary
    Set TestSuite = New AccessTestSuite
    Summary = TestSuite.AddFromVBProject.Run.Summary
End Sub


Erreichbarkeit als COM-AddIn wäre IMHO nicht unbedingt nötig, aber sehr praktisch.
Bernd Gilles
DEV2DEV Softwareentwicklung
Quellcodeverwaltung für Access mit OASIS-SVN
Bernd Gilles
Entwickler
 
Beiträge: 12
Registriert: Mo 22. Mär 2010, 14:54
Wohnort: Willich-Neersen
Accessversion: alles von 2000 bis 2010
Access-Erfahrung: Experte

Re: Schnittstelle für Zugriff aus "fremden" Add-Ins o. ä.

Beitragvon Josef Pötzl » Mi 29. Sep 2010, 00:22

Du musst die Access-Instanz an die AccessTestSuite übergeben und das Set bei Summary nicht vergessen. ;)
Code: Alles auswählen
Dim TestSuite As AccessTestSuite
Dim Summary As ITestSummary
    Set TestSuite = New AccessTestSuite
    Set TestSuite.AccessApplication = Access.Application
    Set Summary = TestSuite.AddFromVBProject.Run.Summary
    Debug.Print Summary.Failed, Summary.Ignored, Summary.Passed, Summary.Total


Zum Testen (oder Forschen :)):
Im Direktfenster
Code: Alles auswählen
CreateObject("AccUnit.Configurator").Init VBE.ActiveVBProject

eingeben.
Das erzeugt die Hilfsklasse TestSuiteStarter und ein Standardmodul zum Erzeugen einer Instanz von dieser Klasse.
Anschließend noch folgenden Code in die Hilfsklasse einfügen:
Code: Alles auswählen
Private Sub m_TestSuite_TestTraceMessage(ByVal Message As String)
  Debug.Print Message ' Debug-Ausgabe obwohl das AccUnit-Add-In aktiviert ist
End Sub

Nun kann ein Testlauf im Direktfenster mit TestSuite.AddFromVBProject.Run gestartet werden.

Die Klasse TestSuiteStarter ist im Prinzip eine Fernsteuerung von AccUnit. ;-)
Josef Pötzl
Moderator
 
Beiträge: 717
Registriert: Mo 30. Nov 2009, 11:08
Wohnort: Klagenfurt
Accessversion: 2010 (2013)

Re: Schnittstelle für Zugriff aus "fremden" Add-Ins o. ä.

Beitragvon Bernd Gilles » Mi 29. Sep 2010, 10:05

cool, mit Delphi klappt's :mrgreen:


quick & dirty Testcode:
Code: Alles auswählen
unit AccUnitTests;

interface

uses
  Access_TLB, AccUnit_Integration_TLB;

type
  TUnitTests = class(TObject)
  private
  public
    function RunAllTests(AccApp: AccessApplication): Integer;
  end;

implementation

{ TUnitTests }

function TUnitTests.RunAllTests(AccApp: AccessApplication): Integer;
var
  TestSuite: IAccessTestSuiteComInterface;
begin
  Result := -1;
  try
    TestSuite := CoAccessTestSuite.Create;
    try
      if TestSuite <> nil then
      begin
        TestSuite.AccessApplication := AccApp;
        Result := TestSuite.AddFromVBProject.Run.Summary.Failed;
      end;
    finally
      TestSuite := nil;
    end;
  except
  end;
end;

end.


Dass ich danach Access nur noch mittels TaskManager schliessen kann, liegt wohl kaum an AccUnit, sondern an meiner etwas verstrubbelten Umgebung mit Vista-64 und A2007.
Auf meiner VM mit Windows 2003-Server und A2010 läuft's dagegen tadellos.
Bernd Gilles
DEV2DEV Softwareentwicklung
Quellcodeverwaltung für Access mit OASIS-SVN
Bernd Gilles
Entwickler
 
Beiträge: 12
Registriert: Mo 22. Mär 2010, 14:54
Wohnort: Willich-Neersen
Accessversion: alles von 2000 bis 2010
Access-Erfahrung: Experte

Re: Schnittstelle für Zugriff aus "fremden" Add-Ins o. ä.

Beitragvon Josef Pötzl » Mi 29. Sep 2010, 10:35

Bernd Gilles hat geschrieben:Dass ich danach Access nur noch mittels TaskManager schliessen kann, liegt wohl kaum an AccUnit, sondern an meiner etwas verstrubbelten Umgebung mit Vista-64 und A2007.
Auf meiner VM mit Windows 2003-Server und A2010 läuft's dagegen tadellos.

In AccUnit wird eine Referenz auf die Access.Application-Instanz und auf VBE gespeichert. Eventuell hilft es, wenn du Dispose explizit aus deiner Anwendung aufrufst.
off-topic:
Gut das du das erwähnt hast, da ich bei der Prüfung in der AccessTestSuite-Klasse feststellte, dass die Access-Referenz nicht explizit entfernt wird, wenn Dispose() aufgerufen wird. ;)
Josef Pötzl
Moderator
 
Beiträge: 717
Registriert: Mo 30. Nov 2009, 11:08
Wohnort: Klagenfurt
Accessversion: 2010 (2013)

Re: Schnittstelle für Zugriff aus "fremden" Add-Ins o. ä.

Beitragvon Christoph Jüngling » Sa 23. Sep 2017, 11:42

Es ist zwar schon etwas länger her, aber ich hänge mich mal hier an :-)

Nach einer vor kurzem entstandenen Idee in meinem Blog möchte ich gern alle anfallenden Aktionen im Zusammenhang mit dem "Build" eines Access-Projektes mit einem CI-System (z.B. Jenkins o.ä.) automatisieren. Mein bisheriger Ansatz ist, die jeweiligen Aktionen von der Kommandozeile aus aufzurufen und als Schnittstelle auch den Win/Dos-Exitcode (0 = ok, andere Werte = Abbruch) zu verwenden. Auf diese Weise würden weitere Steps durch bereits existierende Fremdprogramme übernommen werden können und das Konzept ist leicht erweiterbar.

Aktionen könnten z.B. sein:

  • Checke den aktuellen Stand aus (git clone, git checkout)
  • Baue die Access-Applikation aus dem Quellcode heraus auf (OASIS)
  • Führe alle Tests aus (AccUnit)
  • Lösche aus der Backend-Datei alle Datensätze, die dort nur testweise eingegeben wurden (ADO-Lib, SQL)
  • Füge Zeilennummern (für genauere Fehler-/Logmeldungen) hinzu (MZTools)
  • Mache aus .accdb-Dateien eine .accde (SysCmd 603)
  • Packe alle für das Projekt notwendigen Dateien mittels eines Setup-Scripts zusammen (InnoSetup, MSI, ...)
  • Übertrage die fertige setup.exe an eine Stelle, wo die User sie abholen können (WinScp)
Der Punkt "Testausführung" sollte "Run all tests" in AccUnit auslösen und in der Lage sein zu erkennen, ob alle Tests "Grün" waren. Falls nicht, soll eine Fehlersituation an AccessMake gegeben werden. Und genau hier ist die Frage an euch: Wie geht das?

Das Projekt befindet sich noch im Aufbau, und zwar hier. Ideen sind willkommen :-)
Christoph Jüngling
Tester
 
Beiträge: 43
Registriert: Mi 13. Okt 2010, 09:29
Wohnort: Kassel, Deutschland, Europa, Terra
Accessversion: 2003, 2010
Access-Erfahrung: Experte


Zurück zu AccUnit

cron