Antwoord.

De automatisering van de test van zakelijke logica in complexe applicaties heeft een lange geschiedenis, die begint met de eerste scripts voor het controleren van validators tot moderne microservicetests. Naarmate de architecturen complexer werden (monoliet, SOA, micro- en macroservices) ontstond er een probleem: wijzigingen op het ene niveau van de architectuur breken vaak de tests op andere niveaus.

Probleem is de noodzaak om tests te schrijven die bestand zijn tegen reorganisatie van de interactie tussen de lagen van de applicatie: wijzigingen in contracten, gegevensstructuren, bedrijfsprocessen. Vaak worden tests gekoppeld aan implementatiedetails, waardoor ze "broos" en moeilijk te onderhouden worden.

Oplossing — tests opbouwen volgens het principe van "zwarte doos" met de focus op invoer-/uitvoerdata, gebruikmakend van abstractie lagen voor toegang tot de entiteiten van het systeem (bijvoorbeeld Service Layer en Domain Layer in de architectuur). Het is noodzakelijk om zakelijke logica te scheiden van infrastructuurdetails en om mocks/stubs te gebruiken voor externe afhankelijkheden, om isolatie en stabiliteit van de tests te waarborgen.

Belangrijke kenmerken:

Focus op het testen van contracten: controle van zakelijke invarianten onafhankelijk van interne implementaties.
Gebruik van abstractie lagen voor toegang tot de logica (bijvoorbeeld Application Service → Domain Service → Repository).
Implementatie van mvp/mocks/stubs voor reproduceerbaarheid en isolatie van de testomgeving.

Misleidende vragen.

Wat is het verschil tussen het testen van zakelijke logica via de UI-laag en het testen via API/Domain Layer?

UI-tests zijn vaak minder bestand tegen wijzigingen, omdat de kleinste veranderingen in de interface leiden tot falen van de tests. Tests via de API of Domain Layer zijn minder afhankelijk van de front-end en isoleren de controle van zakelijke regels effectiever.

Moet je alle afhankelijkheden van zakelijke logica mocken voor hun testen?

Nee! Het is niet nodig om te mocken wat kan worden gerealiseerd in de testomgeving (bijvoorbeeld lichtgewicht geheugen in plaats van een database). Mocks zijn nodig voor complexe, dure of externe afhankelijkheden. Volledig mocken kan leiden tot "denkbeeldige" tests die geen echte scenario's weerspiegelen.

Is het voldoende om alleen positieve scenario's te testen voor zakelijke logica?

Nee! Het is belangrijk om alle randgevallen en negatieve scenario's te dekken, anders blijven kritieke fouten onopgemerkt, wat leidt tot kwetsbaarheid van het kern bedrijfsproces.

Typische fouten en anti-patronen

Koppeling van tests aan interne objecten/structuren, broze selectors.
Ontbreken van negatieve/alternatieve paden.
Veel dubbele tests met kleine variaties.

Voorbeeld uit de praktijk

Negatief geval

In het project werd de zakelijke logica alleen getest via UI Selenium-tests, waarbij rechtstreeks met knoppen en formulieren werd gewerkt. Elke refactoring van de front-end leidde tot massaal falen van de automatische tests.

Voordelen:

Snelle initiële dekking van de functionaliteit
Gemakkelijk om de essentie van de scenario's aan het management uit te leggen

Nadelen:

Broosheid: de kleinste wijziging in de UI breekt alles
Langzame, onbetrouwbare tests, moeilijk te onderhouden

Positief geval

In het project werd een laag van API- en eenheidstests geïmplementeerd. De UI dekte alleen kritieke paden, alle andere validatie vond plaats via het service-niveau met het mocken van dure services.