Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add description for fail case XTF files #5

Merged
merged 1 commit into from
Dec 19, 2023
Merged

Add description for fail case XTF files #5

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
47 changes: 46 additions & 1 deletion README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,6 @@ Der Runner funktioniert generisch auf einer entsprechenden Verzeichnisstruktur m
TestSuiteA
ModelToTest.ili
Successful_Data.xtf
(ilivalidator-config.toml)
ModelA.TopicA.ClassA.Constraint1
FailCase-1.xtf
FailCase-2.xtf
Expand All @@ -17,12 +16,58 @@ TestSuiteA
FailCase-1.xtf
…
Output
Successful_Data.log
ModelA.TopicA.ClassA.Constraint1
FailCase-1_Merged.xtf
FailCase-1.log
…
```

Der Runner kann mit folgendem Befehl ausgeführt werden:
```bash
java -jar interlis-testbed-runner.jar --validator <Pfad zu ilivalidator.jar> <Pfad zum Testbed-Ordner (Standard: aktueller Ordner)>
```

Der Runner führt dabei folgende Schritte aus:
- Die XTF-Datei der Basisdaten wird geprüft und muss gemäss Modell gültig sein
- Jede XTF-Datei für einen Fail-Case wird mit den Basisdaten zusammengefügt und im Output-Ordner abgelegt
- Es wird geprüft, dass die zusammengefügten XTF-Dateien gemäss Modell ungültig sind und jeweils mindestens ein Fehler für den Constraint in der Log-Datei vorhanden ist (der Constraint-Name entspricht dabei dem Ordner-Namen vom Fail-Case)

## Aufbau der XTF-Dateien für Failcases
Der Runner kann INTERLIS XTF-Dateien ohne XML-Namespaces oder mit INTERLIS 2.4 Namespace verarbeiten.
Die Header-Section kann bei den Fail-Case Dateien weggelassen werden, da sie von den Basisdaten übernommen wird.

### Hinzufügen oder ersetzen von Elementen
Um für einen Fail-Case ein Objekt zu einem Basket hinzuzufügen oder zu überschreiben, kann es wie in einer XTF-Datei üblich beschrieben werden.
Falls das Objekt mit der angegebenen `TID` im Basket vorhanden ist, wird es mit den hier definierten Attributen überschrieben, ansonsten zum Basket hinzugefügt.

Beispiel `FailCase.xtf` (INTERLIS 2.4):
```xml
<?xml version="1.0" encoding="UTF-8"?>
<ili:transfer xmlns:ili="http://www.interlis.ch/xtf/2.4/INTERLIS" xmlns="http://www.interlis.ch/xtf/2.4/Model">
<ili:datasection>
<Topic ili:bid="<basket id>">
<!-- Das Objekt mit dieser TID wird hinzugefügt oder überschrieben -->
<Class ili:tid="<object id>">
<!-- Attribute -->
</Class>
</Topic>
</ili:datasection>
</ili:transfer>
```

### Entfernen von Elementen
Um für einen Fail-Case ein Objekt aus einem Basket oder einen kompletten Basket zu entfernen, kann dem Element ein `delete`-Attribut hinzugefügt werden.

Beispiel `FailCase.xtf` (INTERLIS 2.4):
```xml
<?xml version="1.0" encoding="UTF-8"?>
<ili:transfer xmlns:ili="http://www.interlis.ch/xtf/2.4/INTERLIS" xmlns="http://www.interlis.ch/xtf/2.4/Model">
<ili:datasection>
<Topic ili:bid="<basket id>">
<!-- Das Objekt mit dieser TID wird aus dem Basket entfernt -->
<Class ili:tid="<object id>" delete="" />
</Topic>
</ili:datasection>
</ili:transfer>
```