rechts unten in der Palette Comet Tests. Der aktuelle Pfad der Testdatei wird links neben diesem Button angezeigt. Einmal eingestellt, bleibt er beim Neustart von Illustrator® erhalten.
Ab priint:comet 4.3
Das Plugin "Tests" stellt die Palette "Tests" zur Verfügung.
Das Plugin stellt lediglich die Benutzeroberfläche zur Verfügung und ist optional.
Comet tests sollen sicherstellen, dass bei einem Release- oder Versionswechsel der priint:comet Plugins oder des verwendeten Illustrator® mögliche Abweichungen oder Fehler schnell entdeckt werden können. Je mehr Tests Sie definiert haben, um so sicherer können Sie sein, dass nach einem Software-Update alles noch wie vorher funktioniert.
Comet tests werden über die Palette Tests definiert und ausgeführt.
Es gibt zwei verschiedenen Typen von Tests: Dokument Tests und Assert Tests.
Jeder Dokument Test führt die folgenden vier Schritte aus (eine detailiertere Beschreibung finden Sie hier) :
Die Korrektheit der Proofs muß manuell geprüft werden. Mehr dazu siehe hier.
Da Dokument-Tests auf Bildvergleichen von Proof- und aktuellen Ergebnissen basieren, können Dokument-Tests nur testen, was sichtbare Spuren hinterläßt. Um beispielsweise die Anzahl erzeugter Dateien in einem Test zu prüfen, muß diese Anzahl z.B durch einen eigefügten Text im Dokument sichtbar gemacht werden. Mehr über Teststrategien finden Sie hier.
Stellen Sie sicher, dass Ihre Tests in einer stabilen, unveränderten Testumgebung ausgeführt werden! Testergebnisse hängen wesentlich davon ab, dass die Testdaten nicht verändert werden. Zur Testumbegung zählt alles, was Einfluß auf das Aussehen des Ergebnisses hat, also Schriften, Bilder, Templates, Platzhalter, Datenbank-Inhalte, usw..
Bei Assert Tests ist das Verfahren wesentlich einfacher, da diese ohne ein Illustrator®-Dokument auskommen. Bei Assert-Tests wird ein Script ausgeführt, in dem der Aufruf der Funktion test::assert (cScript) bestimmt, ob der Test erfolgreich abgelaufen ist oder nicht. Auf diese Weise können Sie selbst die Kriterien festlegen, unter denen ein Test gelingt oder fehlschlägt.
Bitte beachten Sie: Ein Unterlassen des Aufrufs von test::assert wird ebenfalls als Fehler gewertet!
Alle Tests können unterschiedliche Datenquellen verwenden. Dokumente und Aktionen von Tests müssen aber lokal vorliegen (und werden nicht von der externen Datenquelle bezogen).
Die Testdefinition wird in der Datei comet_test_suites.xml der Benutzer-Prefs abgelegt:
Comet-Tests können auch in anderen Dateien abgelegt und aus diesen geladen werden. Verwenden Sie dazu das Button rechts unten in der Palette Comet Tests. Der aktuelle Pfad der Testdatei wird links neben diesem Button angezeigt. Einmal eingestellt, bleibt er beim Neustart von Illustrator® erhalten.
Tests können in beliebig tiefen Treeviews einsortiert werden. Hier ein Beispiel einer verwendeten XML Datei:
<comet_tests>
<structure_version>2</structure_version>
<domain>
<id>2</id>
<name>Base Functions</name>
<description/>
<children>
<domain>
<id>3</id>
<name>Create Frame</name>
<description/>
<children>
<test>
<type>kDocument</type>
<id>4</id>
<name>cScript</name>
<connection></connection>
<file>$DOCUMENTS/CometTests/Base Functions/Create Frame/createFrame_cscript.ai</file>
<prescript></prescript>
<action>$DOCUMENTS/CometTests/Base Functions/Create Frame/createFrame.cpp</action>
<postscript></postscript>
<simulateoverprint>0</simulateoverprint>
<description/>
</test>
</domain>
/children>
</domain>
</comet_tests>
Die Pflege der Testbeschreibungen erfolgt vollständig über die Palette Tests.
Die einzelnen Felder haben dabei folgende Bedeutung:
Pfade dürfen mit den üblichen $-Präfixen für Dateipfade beginnen. Testumgebungen mit so definierten können leicht zwischen verschiedenen Benutzern weitergegeben werden und es ist sicher eine gute Idee, Testdokumente an solchen zentral definierten Pfaden abzulegen. Die Umrechnung der Pfade übernehmen die priint:comet Plugins automatisch. Wenn Sie beim Editieren eines Tests (
oder 
)
also den Pfad
/Users/your_name/Documents/comettests/scripts/aaa.cpp
festlegen, wird im Test automatisch der folgenden Pfad abgespeichert:
$DOCUMENTS/comettests/scripts/aaa.cpp
Zusätzlich ist das Schlüsselwort $DEFINITIONFOLDER definiert und wird durch den Pfad der aktuellen Testdefinitions-Datei ersetzt. Darüberhinaus kann mit ../ an beliebiger Stelle im Pfad der jeweilige Elternordner erreicht werden. Befindet sich die Datei mit den Testdefinitionen also z.B. im Ordner C:/Users/leo/AppData/Local/werkii, wird mit $DEFINITIONFOLDER/../aaa.ai die Datei C:/Users/leo/AppData/Local/aaa.ai adressiert - vom Ordner ...Local/werkii ausgehend einen Ordner nach oben und dann weiter.
Beachten Sie bitte, dass Testdefinitionen unabhängig von Datenverbindungen definiert werden. Verbindungsspezifische Aliasnamen können bei der Definition von Test daher nicht unterstützt werden.
Datenverbindungen werden in der Datei connections.xml definiert. Die Datei hat exakt das gleiche Format wie die connections.xml von Illustrator®, InDesign®, InDesign® Server und comet_pdf. Die Datei muß sich ebenfalls in Ihren Benutzer-Prefs befinden:
<connections>
<connection>
<id>1</id>
<name>demo</name>
<type>odbc_utf8</type>
<server>demo</server>
<user>demo</user>
<password>****</password>
<db>comet_config</db>
<lang></lang>
<client></client>
<passcredentials></passcredentials>
</connection>
</connections>
In der Testbeschreibung kann im Element <connection> auf eine Datenverbindung verwiesen werden. Ist das Element nicht leer, wird vor der Bearbeitung die gewünschte Datenverbindung hergestellt. Nach dem Test wird die Datenverbindung wieder getrennt.
Jeder Dokument-Test benötigt ein eigenes Illustrator®-Dokument. Das Dokument wird in der Testbeschreibung im Feld <file> angegeben und kann sich an beliebiger Stelle im lokalen Netzwerk befinden. Unvollständige Pfade werden relativ zum Benutzerverzeichnis aufgelöst.
Nach der Bearbeitung wird von jeder Zeichenfläche des Dokumentes ein Bild geschossen. Die Bilder werden in Unterordnern "neben" der Illustrator®-Datei abgelegt (siehe Illustrator® Versionen). An den Namen wird jeweils die Zeichenflächennummer angefügt. Testdokumente erhalten außerdem noch die Endung COMET_TEST. Danach wird das Dokument ungesichert wieder geschlossen.
Illustrator® öffnet Dokumente älterer Versionen immer als neue, ungesicherte Dokumente ohne Dateipfad. Tests, die den Dateipfad benötigen (z.B. für Test-Bilder) werden in diesem Fall nicht funktionieren.
Dokumente, die nach dem öffnen keinen Dateipfad haben, werden deshalb nach dem öffnen auf die Originaldatei gesichert. Von der Originaldatei wird vorher eine Kopie mit der Namenendung _TMP_ gemacht. Zum Testende wird die alte Datei wiederhergestellt und die _TMP_ Datei gelöscht.
Soll das Testdokument nach dem Test geöffnet bleiben, wird dieses Verfahren nicht funktionieren, weil die geänderte Originaldatei noch in Benutzung bleibt und deshalb nicht wieder überschrieben werden kann.
Soll das Testdokument nach dem Test geöffnet bleiben, wird deshalb keine Zwischenversion in der aktuellen Illustrator®-Version erstellt und Tests, die auf den Dokumentpfad zugreifen, werden fehlschlagen.
Jeder Test kann bis zu drei Aktionen ausführen:
Alle Skripte werden über Dateipfade definiert. Vorbereitung und Nachbereitung dürfen leer sein, der Test selbst nicht. Die Skripte dürfen sich an beliebiger Stelle im lokalen Netz befinden (aber nicht in einer Datenbank!). Unvollständige Pfade werden relativ zum Benutzerverzeichnis aufgelöst.
Das Vorbereitungsskript wird bereits ausgeführt, bevor das eigentliche Illustrator® Dokument geöffnet wird (nur Dokument-Test) - auf diese Weise kann man z.B. das eigentliche Dokument erst im Vorbereitungsscript erzeugen.
Das Testscript arbeitet auf dem Dokument, das im Test spezifiziert wurde. Bitte beachten Sie, dass das Dokument im Aktionsskript nicht gespeichert werden darf, da Tests immer von der selben Ausgangssituation gestartet werden sollten. Im Falle eines Assert-Tests muss es sich hierbei um ein cScript oder Python Script handeln!
Das Nachbereitungsskript wird ausgeführt, nachdem das Testdokument geschlossen wurde (nur Dokument-Test).
Es wird unter zwei Typen von Skripten unterschieden. Der Skripttyp wird dabei jeweils über die Dateiendung ermittelt:
| Typ | Endung | Beschreibung |
| cScript | c, cp, cpp, crpt |
Valides cScript. Skriptdokument ist das aktuelle Test-Dokument. cScripte sind nicht verschlüsselt. |
| Python | py |
Valides Python script. Skriptdokument ist das aktuelle Test-Dokument. Python Scripte sind nicht verschlüsselt. |
In der Palette Tests befinden sich verschieden Werkzeuge:
| Icon | Beschreibung |
 |
Test ausführenAusführen aller mit einem Auge markierten Tests. Ist kein Auge gesetzt, werden alle Tests durchgeführt - weil das mglw. sehr viele Test sein können, werden Sie in diesem Fall zuvorgefragt, ob Sie wirklich alle Tests ausführen wollen Vor jedem Test werden alle alten Bilder dieses Tests gelöscht. Nach dem Test wird das Statusfeld des Testes gesetzt. Fehler werden in der zweiten Spalte der Liste angezeigt. Bei gedrückter ALT-Taste bleibt der erste ausgeführte Test nach seiner Ausführung geöffnet. So haben Sie die Möglichkeit, das Testergebnis zu prüfen. Schliessen Sie Testdokumente immer, ohne sie zu sichern! Bei gedrückter Strg/CMD-Taste werden die Testresultate gelöscht. |
 |
Proof-Daten erzeugenFür alle mit einem Auge markierten Tests werden neue Proof-Daten erzeugt (also neue Zeichenflächen-Previews angelegt). Ist kein Auge gesetzt, werden Proof-Daten für alle Tests erzeugt. Alte Proof- und Testdaten dieses Tests werden zuvor gelöscht. Ist nur ein Test markiert, werden die erzeugten Proof-Bilder in einem Grafikprogramm geöffnet. Zum Auslösen dieser Aktion muss die ALT-Taste gedrückt sein. Bei gedrückter Strg/CMD-Taste werden die Proof-Daten gelöscht. |
|
Anlegen eines neuen TestsIn einem Dialog werden alle für einen Test nötigen Angaben erfragt. Beachten Sie hierzu auch die Hinweise zum Ablagepfad der verwendeten Dokumente und Skripte. Bei gedrückter Shift-Taste wird eine neue Testdomäne erzeugt. Wenn keine Verbindung zu einer Testdefinitionsdatei besteht, werden Sie aufgefordert den Speicherort für eine neue Datei zu wählen. Diese wird dann automatisch erzeugt und eine Verbindung hergestellt. |
|
Test editierenändern der Daten eines bestehenden Tests. Ermöglicht das Editieren des ausgewählten, bestehenden Tests oder Testdomäne in einem Dialog. Beachten Sie hierzu auch die Hinweise zum Ablagepfad der verwendeten Dokumente und Skripte. Mit gedrückter ALT-Taste öffnen Sie den Ordner, in dem sich das Testdokument (und die Bilder) des Tests befinden. |
 |
Test löschenLöscht den ausgewählten Test/Testdomäne. Für diese Aktion stehen mehrere Modifikatoren zur Verfügung die über Tasten aktiviert werden: Alt: Löscht den Test aus der Liste und der XML-Definition Diese Modifikatoren lassen sich beliebig kombinieren. So löscht eine Kombination von Strg+Alt+Shift den Test und seine zugehörigen Daten endgültig. Wenn eine Testdomäne ausgewählt ist, wird die Aktion für alle Kinder durchgeführt! |
 |
Test neu ladenLädt alle Tests aus der XML-Definition neu. |
|
Verbinden zu TestdateiWechselt die aktuelle XML Testdefinitionsdatei auf der gearbeitet wird. Für diese Aktion stehen mehrere Modifikatoren zur Verfügung die über Tasten aktiviert werden: Alt: Verbindung trennen. Leert die Palette und trennt die Verbindung zu einer Definitionsdatei. |
Tests werden als Knoten in einem Treeview dargestellt. Jeder Knoten repräsentiert dabei entweder einen Test oder eine Testdomäne. Eine Testdomäne stellt einen Container für beliebig viele Tests und Unterdomänen dar. Testdomänen erkennt man an dem blau markiertem Namen.
Testdomänen sind keine Tests und werden nicht durchgeführt, auch nicht wenn sie mit einem Auge versehen sind. Tests selbst erkennt man an einem weiß markiertem Namen. Links neben dem Namen eines Knotens befinden sich verschiedene Statussymbole:
| Icon | Beschreibung |
|
Zeigt, ob ein Test markiert ist. Wenn ein Auge zu sehen ist, wird dieser Test beim Durchführen der Tests oder Erzeugen der Proof-Daten eingeschlossen. Domain-Einträge erhalten ein Auge, wenn mind.einer der enthaltenen Tests ein Auge hat. Das Auge ist eine Schaltfläche und lässt sich per Mausklick aktivieren oder deaktivieren. Markiert man eine Testdomäne mit einem Auge, werden auch alle Kindknoten aktiviert oder deaktiviert. |
  |
Zeigt den Typ des Tests an (Seiten: Dokument Test, Geschweifte Klammern: Assert Test) |
 |
Wenn dieses Symbol erscheint wurde der Test erfolgreich durchgeführt bzw. die Proof-Daten erfolgreich erzeugt. Erscheint dieses Symbol bei einer Testdomäne, wurden alle Kindtests erfolgreich durchgeführt. |
 |
Wenn dieses Symbol erscheint wird der Test gerade durchgeführt. Erscheint dieses Symbol bei einer Testdomäne, wird gerade ein Kindtest durchgeführt. |
 |
Wenn dieses Symbol erscheint gab es Fehler bei der Durchführung eines Tests bzw. der Erzeugung der Proof-Daten. Erscheint dieses Symbol bei einer Testdomäne, gab es Fehler bei mindestens einer der Kindknoten. |
Bei der Durchführung der Tests durchläuft jeder Test folgende Schritte. Schräg geschriebene Schritte sind optional und werden nur ausgeführt, wenn der Test entsprechen konfiguriert ist:
Proofdaten und Testergebnisse von Dokument-Tests werden abhängig vom Betriebssystem und von der Illustrator® Version gespeichert. Dazu werden die Daten in Unterordnern neben der Illustrator® Datei des entsprechenden Tests abgelegt. Diese Unterordner sind folgendermaßen benannt:
(PROOF|TEST)_$OS;/(PROOF|TEST)_ILLU_$ILLUVERSION;
Die Variable $OS; entspricht dem Betriebssystem: "WIN" auf Windows, "MAC" auf dem Mac.
Die Variable $ILLUVERSION; ist dabei die tatsächliche Major Versionsnummer von Illustrator®, nicht die CC Nummer. Sie finden diese Zahl in Illustrator® als erste Nummer unter 'Hilfe->über Illustrator®'.
Also z.B. PROOF_ILLU_27 für Proofdaten von Illustrator® 2023, oder TEST_ILLU_24 für Testdaten von Illustrator® 2020.
Wenn Proof-oder Testdaten von den Comet Tests gelöscht werden, werden immer nur die Daten der aktuellen Illustrator® Version gelöscht!
Werden durch diese änderungen meine existierenden Proofdaten nicht mehr gefunden?
Beim Vergleich der Testdaten mit den Proofdaten gibt es eine Fallback-Methode:
Zunächst wird versucht, Proofdaten der aktuellen Illustrator® Version zu finden. Gelingt dies nicht, wird solange nach Proofdaten älterer Illustrator® Versionen gesucht bis welche gefunden wurden, oder keine entsprechenden Proofdatenordner mehr vorhanden sind. In letzterem Falle wird als letzter Fallback versucht, Proofdaten neben der Illustrator® Datei zu suchen (dort wo sie aus historischen Gründen früher abgelegt wurden).
Sollten keine Proofdaten der aktuellen Illustrator® Version gefunden und stattdessen Daten einer älteren Version verwendet werden, wird eine Warnung ins Logfile geschrieben.
Im Erfolgsfall wird der Test mit einem grünen Icon versehen :
Ordnereinträge der Comet Tests bekommen dieses Icon erst dann, wenn alle Untereinträge ein erfolgreich ausgeführt wurden haben.
Fehlerhafte Tests werden mit einem roten Icon versehen. Der Fehlerstatus wird durch alle Ordnereinträge nach oben weitergegeben:
Neben dem Test-Name erscheint eine kurze Beschreibung der Fehlerursache. Außerdem werden die Fehler in den Tooltip-Text des Testes in der Liste aufgenommen - halten Sie dafür die Maus einen Moment still über dem Testnamen.
Ist die Comet-Option "Logfile schreiben" aktiviert, wird ein separates Test-Logfile am selben Ort wie das Comet-Logfile geschrieben.
Wurde nur ein einzelner Dokument Test ausgeführt und der Test schlug deshalb fehl, weil Proof und aktuelles Ergebnis unterschiedlich sind, werden die ersten beiden unterschiedlichen Bilder in einem geeigneten Grafik-Programm angezeigt.
Um die Ausführung von Tests zu automatisieren, steht eine Reihe von Scriptbefehlen zur Verfügung:
Um die Tests HelloWorld & HelloDocumentWorld anzusprechen, verwenden Sie folgenden Pfad:
"cScript/wlog"
Im folgenden wollen wir einige Strategien beschreiben, wie Tests aussehen können.
Wir haben Testdokumente häufig in Dokumenten mit nebeneinander platzierten Zeichenflächen gemacht: Auf den linken Zeichenfläche sind die Testrahmen, auf den rechten Zeichenfläche die Ergebnisse.
Das erscheint eigentlich unnötig, weil die CometTest ihrerseits nochmal Vorher-Nachher-Bilder machen. Bei fehlgeschlagenen Tests haben Sie es dann aber einfacher, festzustellen, an welcher Stelle der Test fehlschlug.
So können Sie auf recht einfache Weise Platzhalter prüfen lassen:
Mit dem folgenden Skript laden Sie alle Platzhalter eines Dokumentes. Angewendet auf den oben erstellten Platzhalter bewirkt das Skript, dass der Platzhalter der linken Seite geladen wird und der Platzhalter der rechten Seite unverändert bleibt - beide Texte oder Bilder sollten nach dem Test gleich sein. Das Skript legen Sie am besten in einem zentralen Ordner Ihres Testordners (den Sie sich inzwischen längst angelegt) ab.
//
//
// Description : Load all place holders of all frames of the current front document
// Author : Paul Seidel
// Date : 26.Jan 2017
// Copyright (c) : 2017 WERK II, Paul Seidel
//
//**
#include "internal/types.h"
#include "internal/text.h"
int main ()
{
ItemList pl = itemlist::allframes ();
ItemRef fr = item::alloc ();
int i;
for (i = 0; i< itemlist::length (pl); i++)
{
itemlist::get (pl, fr, i);
placeholder::load (fr);
}
return 0;
}
Zum Test eignen sich mglw. auch Gestaltungsregeln gut.
Now you need a script that executes all layout rules after geometry changes of the frames of the document. It is best to place the script in a central folder of your test folder (which you have long since created).
#!py import comet def main(): items = comet.gDocument.getPageItems() item: comet.CFrame for item in items: try: item.applyLayoutRules(comet.kLayoutRuleSituationGeometryChange) except: pass return 0
Wie Eingangs erwähnt, basieren CometTest auf Bildvergleichen. Getestet kann also nur werden, was auch sichtbar gemacht werden kann. Wenn Sie aber testen wollen, ob z.B. eine bestimmte Datei erzeugt wird, sind Comet tests erst einmal nicht brauchbar. In diesem Fall müssen Sie versuchen, die gewünschte Information über ein Script zu testen und das Ergebnis dann als Text ins Testdokument schreiben.
Ein Test soll prüfen, ob ein Dokument gesichert werden kann. Vorstellbar wäre folgendes: Das Testscript sichert das Testdokument. Danach testen Sie, ob an your_path tatsächlich eine Datei liegt und schreiben das Testergebnis in einen Textrahmen:
if (!file::exists (your_path))
{
strcpy (txt, "Test failed : ")
strcat (txt, your_path);
}
else
{
file::remove (your_path);
strcpy (txt, "Test okay");
}
frame::replace (gFrame, txt);
Wenn Sie sicher sind, dass Ihr Test richtig funktioniert, legen Sie den Proof für den Test an. Verwenden Sie dazu den Button der Palette Tests. Zum Anlegen des Proofs eines Tests muß die ALT-Taste gehalten werden.
Folgende Funktionalitäten könnten Sie bei der überprüfung Ihres Test hilfreich sein:
Bei gehaltener ALT-Taste bleibt das Testdokument des ersten ausgeführten Tests geöffnet. Sie können das Ergebnis des Tests also direkt in der Testdatei sehen. Schliessen Sie Datei danach ohne Sichern!
Wenn Sie in der Palette nur einen einzelnen Proof ausführen, werden die erzeugten Proof-Bilder automatisch in einem geeigneten Grafiprogramm geöffnet.
Alt-Klick auf das Edit-Button öffnet den Ordner, der den Test enthält.