Zurück |  | Weiter

## 6.12. Caching von Testdokumenten

### Ausgangssituation

Sie haben viele Tests - das ist gut.

### Problem

Die Tests laufen zu langsam - das ist schlecht.

### Lösungsansatz

Wenn Ihre PDF-Dokumente groß sind, lohnt es sich, diese nur einmal zu instantiieren und anschließend viele Tests darauf auszuführen.

### Lösung

    public class CachedDocumentTestDemo {

      private static DocumentValidator document;

      @BeforeClass  // Document will be instantiated once for all tests:
      public static void loadTestDocument() throws Exception {
        String filename = "documentUnderTest.pdf";
        document = AssertThat.document(filename);
      }

      @Test
      public void test1() throws Exception {
        document.hasNumberOfBookmarks(4);
      }

      // ... and more tests.

    }

Sie könnten zwar auch alle Testmethoden in einer Testmethode verketten. Aber wie würden Sie den Test dann nennen? Der Inhalt einer Testmethode sollte sich möglichst in ihrem Namen widerspiegeln, sonst werden Testreports mit mehreren hundert Tests schwer verständlich. `testAll` ist daher ein schlechter Name, er ist bedeutungsleer.

PDFUnit arbeit intern zustandslos. Da aber auch verschiedene externe Bibliotheken verwendet werden, kann die Zustandslosigkeit nicht zu 100% garantiert werden. Sollte es Probleme geben, ändern Sie die Annotation `@BeforeClass` in `@Before` und entfernen den `static` Modifier. Dann wird das PDF-Dokument wieder für jeden Test neu instantiiert:

    @Before  // Document will be instantiated for each test. No caching:
    public void loadTestDocument() throws Exception {
      String filename = "documentUnderTest.pdf";
      document = AssertThat.document(filename);
    }

Zurück | Nach oben | Weiter
6.11. PDF aus einer Datenbank lesen und testen | Zum Anfang | Kapitel 7. PDFUnit für Nicht-Java Systeme