Können war das falsche Wort. Dürfen hätte ich wohl sagen sollen. Das steht irgendwo in meinen Slides: Unit Tests dürfen nicht auf DB, Filesystem oder Internet zugreifen, da sie schnell sein sollen. In Ihrem Fall ist also gemäß meiner Definition ihr Test automatisch ein Integrationstest. Auch wenn er den Jenkins gar nicht braucht.
Für den Vortrag spielt das keine Rolle, der Inhalt des Tests bleibt ja gleich, ob nun im Namen Unit oder Integrationstest steht. Stellen Sie daher einfach Ihre Tests vor, der Inhalt ist ja genau das, was ich wollte: es werden verschiedenen Dateien entpackt, eingelesen und aggregiert. Das ganze als Jenkins Integrationstest umzuwandeln ist für heute nicht nötig.
(Wenn Sie das später noch so umwandeln, dass das im Jenkins entpackt wird, lassen sich noch weitere Aspekte testen, die bei Ihnen jetzt nicht möglich sind: was passiert, wenn der Scanner auf einem anderen Rechner läuft als der Master. Lassen sich alle Daten des Report serialisieren? Werden alle Daten auch in der Info-View des Jenkins angezeigt? etc. Das Thema werden wir dann sicher auch wieder bei den UI Tests aufgreifen, der Übergang ist fließend.) Aber das können wir dann im Anschluss heute noch kurz ansprechen, kümmern Sie sich erst mal um den Vortrag!
Mir ist grad mit erschrecken aufgefallen, dass ich den FilesScanner auch komplett ohne irgendwelche Integrationen testen kann, da er keinerlei Abhängigkeiten hat. D.h. ich muss meine Testklasse nicht mal von "IntegrationsTest" ableiten, sondern kann das als normal JUnit test ausführen. Das ist jetzt natürlich ein Problem. Was soll ich da jetzt machen? Weil so macht es ja keinen Sinn.