Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Moin,
fange nun an Tests zu schreiben. Unit und Integrationstests. Hat jemand paar Tipps um das "sauber" zu machen? Dinge die ihr vielleicht falsch gemacht habt und nun besser wisst? Nutzt ihr Profile in euren Tests und wenn ja warum/wofür? Mehrere Properties ? Freue mich über Tipps und Hinweise
1. halte dich immer an die Testpyramide: Viele Unit Tests (unten), wenige Integrationstests (oben)
2. nutze nur einen Spring Container, wenn es wirklich sinnvoll ist (du willst nicht für jeden einzelnen Test einen Spring Container hochfahren -- auch, wenn sie mit derselben Config gecached werden. Ich habe schon Projekte gesehen, wo die "Unit"-Tests eine halbe Stunde brauchten, weil für jede einzelne Unit under Test ein ganzer Spring Container hochgefahren wurde, darin eine Bean erzeugt wurde, die dann in den Test injected wurde, und dann getestet wurde.
3. nutze _nur_ Constructor Injection, keine Autowired Felder (ist eh best practice) -> das erlaubt dir, auch mal bei nur zwei, drei "Beans" diese in einem normalen nicht-Spring Unit Test zu erzeugen und zu verwiren/verbinden
4. je weniger Abhängigkeiten und Responsibilities deine Klassen/Beans haben, desto besser lassen sie sich testen und desto einfacher werden die Tests
1. halte dich immer an die Testpyramide: Viele Unit Tests (unten), wenige Integrationstests (oben)
2. nutze nur einen Spring Container, wenn es wirklich sinnvoll ist (du willst nicht für jeden einzelnen Test einen Spring Container hochfahren -- auch, wenn sie mit derselben Config gecached werden. Ich habe schon Projekte gesehen, wo die "Unit"-Tests eine halbe Stunde brauchten, weil für jede einzelne Unit under Test ein ganzer Spring Container hochgefahren wurde, darin eine Bean erzeugt wurde, die dann in den Test injected wurde, und dann getestet wurde.
3. nutze _nur_ Constructor Injection, keine Autowired Felder (ist eh best practice) -> das erlaubt dir, auch mal bei nur zwei, drei "Beans" diese in einem normalen nicht-Spring Unit Test zu erzeugen und zu verwiren/verbinden
4. je weniger Abhängigkeiten und Responsibilities deine Klassen/Beans haben, desto besser lassen sie sich testen und desto einfacher werden die Tests
Zu Punkt 1: Habe das eher anders gehört. Macht in der Theorie zwar Sinn, aber da ich aktuell keine komplexen methoden habe, macht es eher sinn mehr integrationstests zu haben, als Unittests.
Zu Punkt 2: Aktuell habe ich nur die Annotation @SpringBootTest und dann die Tests. Sobald ich den Test starte fährt die komplette Anwendung hoch, meinst du das? Wie löse ich das am besten? Vielleicht ein Codebeispiel? Hat das was mit dem @ContextConfiguration zu tun?
Zu Punkt 3: Da ich schonnmal Tests geschrieben habe hatte ich dieses Problem gehabt .Deshalb sind in diesem Projekt alle Abhängigkeiten immer via Construktoren überführt. Passt also
Zu Punkt 1: Habe das eher anders gehört. Macht in der Theorie zwar Sinn, aber da ich aktuell keine komplexen methoden habe, macht es eher sinn mehr integrationstests zu haben, als Unittests.
Es gibt keinen Grad an "Komplexität", ab der ein Integrationstest "mehr Sinn" macht als ein Unit-Test.
Sobald eine Klasse oder eine Methode eine Zuständigkeit hat und diese implementiert, kann man dafür einen Unit-Test schreiben. Das dient letztlich der Regressionssicherheit: Code wird später eventuell refactored oder anderweitig verändert. Und, man möchte immer noch sicherstellen, dass der Code das macht, was er soll.
Bei Unit-Tests solltest du eher alle möglichen Fälle für Input-Kombinationen abtesten, so dass du dir sicher bist, dass eben dieser Teil deiner Anwendung funktioniert.
Integrationstests sollten eher genutzt werden, um einmal für einen "Happy-Path" die Konfiguration der Anwendung zu testen, die bei Spring / Spring Boot auch gerne mal schiefgehen kann. Hier ein @Bean vergessen oder hier ein @Configuration oder dort ein excludes/includes und schon funktionieren zwar alle Unit-Tests aber eben nicht die gesamte Anwendung.
Zu Punkt 2: Aktuell habe ich nur die Annotation @SpringBootTest und dann die Tests. Sobald ich den Test starte fährt die komplette Anwendung hoch, meinst du das? Wie löse ich das am besten? Vielleicht ein Codebeispiel? Hat das was mit dem @ContextConfiguration zu tun?
Du schreibst eben ganz einfache Unit-Tests (ohne Spring oder SpringBoot Integration). Also nichts mit @SpringBootTest. Einfach nur JUnit oder TestNG Tests.
Im besten Fall hängt die Funktionalität/Fachlichkeit und Testbarkeit deiner Anwendung in keinster Weise von dem Vorhandensein eines Container- bzw. DI-Frameworks ab.
