Customizing
Quality Toolkit wird bereits mit einem Satz von Bibliotheksfunktionen für allgemeine Aufgaben ausgeliefert mit denen sich bereits viele Funktionen automatisiert testen lassen. Quality Toolkit unterstützt auch projektspezifische Bibliotheksfunktionen zur Erweiterung des Funktionsumfanges.
Info
Die Erstellung von projektspezifischen Erweiterungen setzt Kenntnisse in der Programmiersprache c# und Erfahrung mit dem .NET Framework voraus.
Übungsbeispiel
Der nachfolgende Abschnitt beschreibt die Erstellung einer projektspezifischen Bibliothek und die Erstellung eines einfachen Tests. Zur Demonstration wird ein Test implementiert, der die SystemUID eines COMOS Objektes prüft.
c# Projekt
Die Bibliotheksfunktionen müssen in einer c# Klassenbibliothek mit Unterstützung für das .NET Framework implementiert werden. Der Dateiname der Assembly muss dabei der Konvention QTK.Name.dll entsprechen, die Klassen innerhalb der Assembly werden im Namespace Stupka.QTK.Name erwartet.
Als Referenz müssen Sie zumindest die Assembly QTK.Shared.dll in das Projekt einbinden. Für die Entwicklung von Funktionen die im Umfeld von COMOS lauffähig sein sollten sind zusätzlich Referenzen auf Plt.Comos.dll und QTK.Comos.dll erforderlich.
Für das Beispiel erstellen Sie eine Bibliothek mit dem Namen QTK.Training.dll und implementieren die Klassen im Namespace Stupka.QTK.Training.
Bibliotheksfunktion
Jede neue Bibliotheksfunktion wird in einer separaten Klasse erstellt, wobei die Klasse eine der folgenden Schnittstellen implementieren muss. Technisch gibt es aktuell noch keinen Unterschied zwischen IExecutor, ITest und IWaiter, es wird jedoch empfohlen von Beginn an die richtige Schnittstelle zu implementieren.
- Stupka.QTK.Shared.ISelector<Type>
- Stupka.QTK.Shared.IExecutor
- Stupka.QTK.Shared.ITest
- Stupka.QTK.Shared.IWaiter
Info
Funktionen die "etwas" selektieren, damit mit dem Ergebnis in einer anderen Funktion weitergearbeitet werden kann, müssen das Interface Stupka.QTK.Shared.ISelector<T> implementieren und eine Funktion T GetSelectedObject() bereitstellen. In diesem Beispiel wird ein Test erstellt, der das Interface Stupka.QTK.Shared.ITest implementiert.
Für das beschriebene Beispiel können Sie mit der folgenden Implementierung beginnen:
using Stupka.QTK.Comos;
using Stupka.QTK.Shared;
using System;
namespace Stupka.QTK.Training
{
public class ObjectSystemUIDTest : ITest
{
public State Run(IAgent agent, IFeedbackCollector feedback)
{
throw new NotImplementedException();
}
}
}
Parameter
Spezifische Parameter müssen als öffentliche Properties implementiert werden, dadurch werden diese vom Schemagenerator Define bereits als gültige Parameter erkannt. Einen zwingend notwendigen Parameter können Sie durch das Attribut [QTKRequired] kennzeichnen. Öffentliche Properties, die nicht in der Schemadefinition erscheinen sollen können Sie mit dem Attribut [QTKIgnore] kennzeichnen.
Für das anfangs beschriebebe Beispiel benötigen Sie zwei Parameter, die Sie wie folgt implementieren können:
protected IComosObjectContainer<Plt.IComosDDevice> comosobject = null;
protected string systemuid = null;
[QTKRequired]
public IComosObjectContainer<Plt.IComosDDevice> ComosObject
{
get { return comosobject; }
set { comosobject = value; }
}
[QTKRequired]
public string SystemUID
{
get { return systemuid; }
set { systemuid = value; }
}
COMOS Integration
Die Bibliotheksfunktion benötigt einen Parameter mittels dem das zu testende COMOS Objekt übergeben werden kann - das COMOS Objekt ist aus Serialisierungsgründen in einem IComosObjectContainer<Type> gekapselt. Ist für eine Funktion (oder einen Test) Zugriff auf COMOS notwendig, so könnten Sie über den Agent (ein Parameter der Run Methode) auf den Plt.IComosDWorkset zugegriffen werden.
Für das anfangs beschriebene Beispiel können Sie in der Funktion Run die SystemUID des übergebenen Objektes gegen den gewünschten Wert prüfen.
public State Run(IAgent agent, IFeedbackCollector feedback)
{
// ComosAgent comos = agent as ComosAgent;
// Plt.IComosDWorkset workset = comos.Workset;
Plt.IComosDDevice device = comosobject.GetComosObject();
feedback.AddFeedback(FeedbackCategory.DEBUG, String.Format("Test for SystemUID {0}", systemuid));
return (device.SystemUID().Equals(systemuid)) ? State.OK : State.FAILED;
}
Dokumentation
Bei der Erzeugung der Schemadatei Script.xsd durch das Hilfsprogramm Define wird neben den Eigenschaften der Klassen auch eine textuelle Beschreibung der Klasse bzw. der Properties berücksichtigt. Diese Beschreibung wird in einer Textdatei mit dem Namen der Klasse in einem Verzeichnis "Documentation" hinterlegt und in die Assembly einkompiliert. Dazu muss die Build Aktion auf "Embedded Resource" gestellt werden. Für das Beispiel muss die Datei in dem c# Projekt unter ".\Dokumentation\ObjectSystemUIDTest.md" abgespeichert sein.
[Title]
Tests a COMOS object for a SystemUID.
[Property.ComosObject]
Reference to a selector holding a COMOS object.
[Property.SystemUID]
Expected SystemUID.
Verwendung
Nachdem Sie die Assembly erfolgreich kompiliert haben, kann diese bereits in einem Testskript verwendet werden. Zusätzlich zur Erstellung der Assembly ist auch noch die Aktualisierung des Schemas über das Hilfsprogramm Define notwendig.
<?xml version="1.0" encoding="utf-8" ?>
<Script identifier="T-01" comment="..." xmlns="http://www.stupka.at/qtk">
<Positions>
<Group comment="Init">
<Comos.CDeviceByNameSelector identifier="cdevice" systemfullname="@30|M00|A30|A20|A10|A20|A10" comment="..." />
</Group>
<Group comment="Test">
<Training.ObjectSystemUIDTest comosobject="cdevice" systemuid="XXXXXXXXXX" comment="Expected result: Failure" />
<Training.ObjectSystemUIDTest comosobject="cdevice" systemuid="A3819F3PFQ" comment="Expected result: Success" />
</Group>
</Positions>
</Script>