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 InDesign® erhalten.
CometTests sollen sicherstellen, dass bei einem Release- oder Versionswechsel der priint:comet Plugins oder des verwendeten InDesign® 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.
CometTests werden über die Palette CometTest 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 InDesign®-Dokument auskommen. Bei Assert-Tests wird ein cScript ausgeführt, in dem der Aufruf der Funktion test::assert 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 InDesign® 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.indd</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 Comet 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.indd die Datei C:/Users/leo/AppData/Local/aaa.indd 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 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 InDesign®-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 jedem Spread des Dokumentes ein Bild geschossen. Die Bilder werden in Unterordnern "neben" der InDesign®-Datei abgelegt (siehe InDesign® Versionen). An den Namen wird jeweils die Spreadnummer angefügt. Testdokumente erhalten außerdem noch die Endung COMET_TEST. Danach wird das Dokument ungesichert wieder geschlossen.
InDesign® ö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 InDesign®-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 InDesign® 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 fünf 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. |
| JavaScript | js, jsx, javascript |
Valides InDesign®-JavaScript. War vor Teststart kein weiteres Dokument geöffnet, ist das Testdokument das erste Dokument von app.documents: var myDocument = app.documents.item(0); |
| AppleScript | scpt, applescript |
Valides AppleScript. Mit $$APP$$ bezeichnen Sie den Namen des aktuell ausführenden InDesigns®. War vor Teststart kein weiteres Dokument geöffnet, ist das Testdokument das aktive Dokument: tell application "$$APP$$" |
| Produktliste | xml |
Produktaufbau. Im Testdokument wird ein kompletter Produktaufbau durchgeführt. Die Datei enthält die aufzubauenden Produkte und ihre Seitenelemente. Format und Erstellung dieser Dateien sind in der Dokumentation von comet_pdf ausführlich beschrieben. Haben Sie diese Datei einmal erzeugt, kann der Test mit Hilfe dieser Datei den Produktaufbau wiederholen. |
In der Palette Comet 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. Schließen 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 Spread-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. |
 |
Tests importierenImportiert vorhandene Testdefinitionen aus einer XML Datei. 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. |
 |
Tests exportierenExportiert die Selektierten Tests in eine XML Datei. Wenn eine Testdomäne ausgewählt ist, werden alle darunterliegenden Domänen und Tests ebenfalls exportiert. Die erhaltene Datei kann als Testdefinitionsdatei verwendet werden. |
|
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 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. |
 |
Wenn dieses Symbol erscheint fehlen für den Testknoten die Proof-Daten und müssen erst noch erzeugt werden. Erscheint dieses Symbol bei einer Testdomäne, fehlen die Proof-Daten bei mindestens einem 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 InDesign® Version gespeichert. Dazu werden die Daten in Unterordnern neben der InDesign® Datei des entsprechenden Tests abgelegt. Diese Unterordner sind folgendermaßen benannt:
(PROOF|TEST)_$OS;/(PROOF|TEST)_ID_$IDVERSION;
Die Variable $OS; entspricht dem Betriebssystem: "WIN" auf Windows, "MAC" auf dem Mac.
Die Variable $IDVERSION; ist dabei die tatsächliche Major Versionsnummer von InDesign®, nicht die CC Nummer. Sie finden diese Zahl in InDesign® als erste Nummer unter 'Hilfe->Über InDesign®' an der Stelle "Build".
Also z.B. PROOF_ID_16 für Proofdaten von InDesign® 2021, oder TEST_ID_15 für Testdaten von InDesign® 2020.
Wenn Proof-oder Testdaten von den Comet Tests gelöscht werden, werden immer nur die Daten der aktuellen InDesign® 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 InDesign® Version zu finden. Gelingt dies nicht, wird solange nach Proofdaten älterer InDesign® Versionen gesucht bis welche gefunden wurden, oder keine entsprechenden Proofdatenordner mehr vorhanden sind. In letzterem Falle wird als letzter Fallback versucht, Proofdaten neben der InDesign® Datei zu suchen (dort wo sie vor R19216 abgelegt wurden).
Sollten keine Proofdaten der aktuellen InDesign® Version gefunden und stattdessen Daten einer älteren Version verwendet werden, wird eine Warnung ins Logfile geschrieben.
Im Erfolgsfall wird der Test mit einem Häkchen versehen :
Ordnereinträge der Comet Tests bekommen dieses Häkchen erst dann, wenn alle Untereinträge ein Häkchen haben.
Fehlerhafte Tests werden mit einem roten Ausrufezeichen 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 gelben Tipp-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 Graphik-Programm angezeigt.
Seit Comet 4.1 werden Comet-Tests auch im InDesign® Server Betrieb unterstützt. Hierfür sind in der cScript-Klasse test eine Reihe neuer cScript-Befehle hinzugekommen. Diese Befehle sind selbstverständlich auch im Desktop Betrieb einsetzbar. Die Befehle arbeiten in der Regel mit dem sogenannten Testpfad. Das ist der Pfad mit dem der Testeintrag in der Hierarchie des Baumes zu finden (und nicht etwa der Dateipfad der Testdatei!). Trennzeichen sind dabei normale Slashes "/". Zeigt dieser Pfad auf eine Domäne, werden alle darunterliegenden Tests berücksichtigt. Um alle Tests zu berücksichtigen, verwenden sie einen leeren Pfad.
Um die Tests create, create_columns, embed_image, ... anzusprechen, verwenden Sie folgenden Pfad:
"cScript/frame"
Im folgenden wollen wir einige Strategien beschreiben, wie Tests aussehen können.
Am häufigsten verwendet und am einfachsten zu konfigurieren sind Tests des Produktaufbaus. Verwenden Sie als Testdokument dazu einfach das Dokument, das Sie auch zum Aufbau verwenden. Nachdem Sie den Aufbau gemacht haben, sichern Sie die Produkte des Dokumentes wie hier beschrieben. Danach machen Sie den Aufbau rückgängig, legen die erzeugte Produkte-XML und eine Kopie des Testdokuments in einen Ordner Ihrer Wahl und legen mit den Test an.
Wir haben Testdokumente häufig in doppelseitigen Dokumenten gemacht: Auf den linken Dokumentseiten sind die Testrahmen, auf den rechten Dokumentseiten 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.
Im Bild sehen Sie eine typische Seite unseres Testdokumentes für Bildplatzierungen: Links die Rahmen vor der Anwendung der Gestaltungsregel Bildplatzierung anpassen, rechts nach der Bildplatzierung. Geht ein so gestalteter Test mal schief, ist es jetzt ziemlich einfach, die Fehlerstelle zu finden.
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;
}
Analog dem oben beschriebenen Verfahren zum Testen von Platzhaltern können Sie vorgehen, um Aktionen zu testen, die nicht in Platzhaltern definiert sind. Dazu können Sie in der XML-Struktur des Dokumentes Rahmen mit cScripten verbinden. Diese Skripte werden dann vom CometTest ausgeführt.
So definieren Sie cScripte in der Dokument-XML-Struktur:
Klingt aufwendig, ist es aber nicht. Die Schritte 1-4 müssen Sie nur einmal machen. Evtl. muß der Liste der Skriptnamen noch ein weiterer Eintrag hinzugefügt werden.
So definierte XMLStruktur-Skripte können in der Palette Fenster -> Comet Admin -> Comet ausgeführt werden.
Mit dem so definierten Skript am Rahmen ist der Test einfach zu erstellen:
Jetzt benötigen Sie nur noch ein Skript, das alle cScripte der XML-Dokumentstruktur der Rahmen des Dokumentes ausführt. Das Skript legen Sie am besten in einem zentralen Ordner Ihres Testordners (den Sie sich inzwischen längst angelegt) ab.
//**
//
// Description: Execute cscripts defined in the XML structure for all
//frames of the current front document
// Author: Paul Seidel
// Date: 26.Jan 2017
// Copyright (c): 2017 WERK II, Paul Seidel
//
//**
int main ()
{
ItemList li = itemlist::allframes ();
int i;
ItemRef fr = item::alloc ();
for (i = 0; i < itemlist::length (li); i++)
{
itemlist::get (li, fr, i);
xml::exec (fr);
}
return 0;
}
Zum Test eignen sich mglw. auch Gestaltungsregeln ganz gut. Das Verfahren ist änhlich dem der cScripte in der XML-Struktur des Dokumentes:
Jetzt benötigen Sie noch ein Skript, das alle Gestaltungsregeln nach Geomtrieänderungen der Rahmen des Dokumentes ausführt. Das Skript legen Sie am besten in einem zentralen Ordner Ihres Testordners (den Sie sich inzwischen längst angelegt) ab.
//**
//
// Description: Apply layout rules 'After geometry changes' for all
// frames of the current front document
// Author: Paul Seidel
// Date: 26.Jan 2017
// Copyright (c): 2017 WERK II, Paul Seidel
//
//**
int main ()
{
ItemList li = itemlist::allframes ();
int i;
ItemRef fr = item::alloc ();
for (i = 0; i < itemlist::length (li); i++)
{
itemlist::get (li, fr, i);
frame::apply_layout_rules (fr, 8);
}
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 CometTests erst einmal nicht brauchbar. In diesem Fall müssen Sie versuchen, die gewünschte Information über cScript zu testen und das Ergebnis dann als Text ins Testdokument schreiben.
Ein Test soll prüfen, ob ein Dokument verpackt werden kann. Vorstellbar wäre folgendes : Fügen Sie an einen beliebigen Rahmen des Dokumentes ein Dokument-XML-cScript. (siehe hier). Das Skript verpackt mit document::export_ (0, your_path, "package", "", 0, 2, ...) das aktuelle Dokument . Danach testen Sie, ob an your_path tatsächlich eine Datei liegt und schreiben das Testergebnis in den Rahmen:
if (!file::exists (your_path))
{
strcpy (txt, "<ParaStyle:><cFont:Arial>Test failed : ")
strcat (txt, your_path);
}
else
{
file::remove (your_path);
strcpy (txt, "<ParaStyle:><cFont:Arial>Test okay");
}
frame::replace (gFrame, txt);
Der Test selbst wird dann mit dem Skript aus dem Absatz XML-Dokumentstruktur angelegt.
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 CometTests. 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. Schließen 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.