Sie haben viele Tests - das ist gut.

Die Tests laufen zu langsam - das ist schlecht.

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

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);
}