Hoe DELETE-verzoeken te testen voor API-testen met Playwright Java

API-testen heeft de laatste tijd veel aan populariteit gewonnen. Aangezien de gebruikersinterface niet betrokken is, is het veel gemakkelijker en sneller om te testen. Dit is de reden waarom API-testen wordt beschouwd als de eerste keuze voor het uitvoeren van end-to-end testen van het systeem. Het integreren van de geautomatiseerde API-tests met de CI/CD-pijplijnen stelt teams in staat om sneller feedback te krijgen op de builds.

In deze blog zullen we het hebben over en leren over DELETE API-verzoeken en hoe we deze kunnen afhandelen met Playwright Java voor automatiseringstesten, waarbij we de volgende punten behandelen:

1. Wat is een DELETE-verzoek?
2. Hoe test je DELETE-API’s met Playwright Java?

Aan de Slag

Het wordt aanbevolen om de eerder gepubliceerde tutorialblog te bekijken om meer te leren over de details met betrekking tot vereisten, installatie, en configuratie.

Toepassing Onder Test

We zullen gebruikmaken van de gratis te gebruiken RESTful e-commerce API’s die meerdere API’s aanbieden met betrekking tot orderbeheerfunctionaliteit, waarmee we bestellingen kunnen aanmaken, ophalen, bijwerken en verwijderen.

Deze applicatie kan lokaal worden opgezet met behulp van Docker of NodeJS.

Wat is een DELETE-verzoek?

Een DELETE API-verzoek verwijdert de opgegeven resource van de server. Over het algemeen is er geen responsbody in de DELETE-verzoeken.

De resource wordt aangegeven door een URI en de server verwijdert deze permanent. DELETE-verzoeken worden niet beschouwd als veilig of idempotent, omdat ze bijwerkingen op de server kunnen veroorzaken, zoals het verwijderen van gegevens uit een database.

Hier zijn enkele beperkingen van DELETE-verzoeken:

1. De gegevens die worden verwijderd met een DELETE-verzoek zijn niet herstelbaar, dus ze moeten voorzichtig worden behandeld.
2. Het wordt niet beschouwd als een veilige methode omdat het rechtstreeks de resource uit de database kan verwijderen, wat conflicten in het systeem kan veroorzaken.
3. Het is geen idempotente methode, wat betekent dat het meerdere keren voor dezelfde resource aanroepen kan leiden tot verschillende toestanden. Bijvoorbeeld, bij de eerste keer dat DELETE wordt aangeroepen, zal het Statuscode 204 retourneren waarin staat dat de resource is verwijderd, en als DELETE opnieuw wordt aangeroepen voor dezelfde resource, kan het een 404 NOT FOUND geven omdat de opgegeven resource al is verwijderd.

Hier is een voorbeeld van het DELETE API-eindpunt van het RESTful e-commerceproject. 

DELETE /deleteOrder/{id} :  Verwijdert een bestelling op basis van ID

Voor dit API is de order_id vereist als Padparameter om de respectievelijke bestelling uit het systeem te verwijderen. Er is geen verzoekbody nodig om te worden verstrekt in dit DELETE API-verzoek. Echter, als beveiligingsmaatregel moet de token worden verstrekt als een header om de bestelling te kunnen verwijderen.

Zodra de API is uitgevoerd, verwijdert deze de opgegeven bestelling uit het systeem en retourneert Statuscode 204.

In het geval dat de bestelling niet gevonden wordt, of de token niet geldig of niet verstrekt is, zal het overeenkomstig de volgende reactie tonen:

Hoe DELETE API’s testen met Playwright Java

Het testen van DELETE API’s is een belangrijke stap om de stabiliteit en betrouwbaarheid van de applicatie te waarborgen. Een correcte implementatie van de DELETE API’s is essentieel om onbedoeld dataverlies en inconsistenties te controleren, aangezien de DELETE API’s verantwoordelijk zijn voor het verwijderen van de middelen uit het systeem.

In deze demonstratie van het testen van DELETE API’s met Playwright Java, zullen we de /deleteOrder/{id} gebruiken om een bestaande bestelling uit het systeem te verwijderen.

Testscenario 1: Verwijder een geldige bestelling

1. Start de RESTful e-commerce service.
2. Gebruik een POST-verzoek om enkele bestellingen in het systeem te maken.
3. Verwijder de bestelling met order_id “1” met behulp van een DELETE-verzoek.
4. Controleer of de Statuscode 204 in de reactie wordt geretourneerd.

Testimplementatie

De volgende stappen moeten worden uitgevoerd om het testscenario te implementeren:

1. Voeg nieuwe bestellingen toe met behulp van het POST-verzoek.
2. Roep de /auth API aan om een token te genereren.
3. Roep het API-eindpunt /deleteOrder/ aan met het token en de order_id om de bestelling te verwijderen.
4. Controleer dat de Status Code 204 wordt geretourneerd in de respons.

Een nieuwe testmethode, testShouldDeleteTheOrder(), wordt aangemaakt in de bestaande testklasse HappyPathTests. Deze testmethode implementeert de bovenstaande drie stappen om het DELETE API te testen.

@Test

    public void testShouldDeleteTheOrder() {

​

        final APIResponse authResponse = this.request.post("/auth", RequestOptions.create().setData(getCredentials()));

​

        final JSONObject authResponseObject = new JSONObject(authResponse.text());

        final String token = authResponseObject.get("token").toString();

​

        final int orderId = 1;

        final APIResponse response = this.request.delete("/deleteOrder/" + orderId, RequestOptions.create()

                .setHeader("Authorization", token));

        assertEquals(response.status(), 204);

    }

Het POST /auth API-eindpunt zal eerst worden aangeroepen om het token te genereren. Het token ontvangen in de respons wordt opgeslagen in de variabele token om verder te worden gebruikt in het DELETE API-verzoek.

Vervolgens zullen nieuwe bestellingen worden gegenereerd met behulp van de methode testShouldCreateNewOrders(), die al is besproken in de vorige zelfstudie, waar we spraken over het testen van POST-verzoeken met behulp van Playwright Java.

Nadat de bestellingen zijn gegenereerd, is de volgende stap om het DELETE-verzoek te sturen met de geldige order_id dat de specifieke bestelling zal verwijderen.

We zullen de bestelling met de order_id “1” verwijderen met behulp van de delete() -methode die door het Playwright-framework wordt geleverd.

Nadat de bestelling is verwijderd, wordt de Status Code 204 als reactie teruggegeven. Er wordt een assertie uitgevoerd op de Status Code om te verifiëren dat de Delete-actie succesvol was. Aangezien er geen aanvraaglichaam in de respons wordt teruggegeven, is dit het enige dat kan worden geverifieerd.

Testuitvoering

We zullen een nieuw testng.xml-bestand maken met de naam testng-restfulecommerce-deleteorders.xml om de tests uit te voeren in de volgorde van de stappen die we hebben besproken in de testimplementatie.

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">

<suite name="Restful ECommerce Test Suite">

    <test name="Testing Happy Path Scenarios of Creating and Updating Orders">

        <classes>

            <class name="io.github.mfaisalkhatri.api.restfulecommerce.HappyPathTests">

                <methods>

                    <include name="testShouldCreateNewOrders"/>

                    <include name="testShouldDeleteTheOrder"/>

                </methods>

            </class>

        </classes>

    </test>

</suite>

Eerst zal de testShouldCreateNewOrders() testmethode worden uitgevoerd, en deze zal nieuwe bestellingen aanmaken. Vervolgens zal de testShouldDeleteTheOrder() test methode worden uitgevoerd om de delete order API te testen.

De volgende screenshot van de testuitvoering uitgevoerd met IntelliJ IDE toont aan dat de tests succesvol zijn uitgevoerd.

Laten we nu verifiëren dat de bestelling correct is verwijderd door een nieuwe test te schrijven die de GET /getOrder API-endpoint aanroept met de verwijderde order_id.

Testscenario 2:  Haal de Verwijderde Bestelling Op

1. Verwijder een geldige bestelling met order_id “1.”
2. Gebruik de GET /getOrder API en probeer de bestelling op te halen met order_id “1.”
3. Controleer of de Status Code 404 wordt teruggegeven met de boodschap “Geen bestelling gevonden met de gegeven parameters!” in de respons.

Testimplementatie

Laten we een nieuwe testmethode maken, testShouldNotRetrieveDeletedOrder(), in de bestaande klasse HappyPathTests.

@Test

    public void testShouldNotRetrieveDeletedOrder() {

        final int orderId = 1;

        final APIResponse response = this.request.get("/getOrder", RequestOptions.create().setQueryParam("id", orderId));

​

        assertEquals(response.status(), 404);

​

        final JSONObject jsonObject = new JSONObject(response.text());

        assertEquals(jsonObject.get("message"), "No Order found with the given parameters!");

    }

De testimplementatie van dit scenario is vrij eenvoudig. We zullen de GET /getOrder API uitvoeren om de verwijderde bestelling met order_id “1” op te halen.

Een assertie wordt vervolgens toegepast om te verifiëren dat de GET API de Statuscode 404 in de reactie moet retourneren met de boodschap “Geen bestelling gevonden met de gegeven parameters!”

Deze test zorgt ervoor dat de verwijderbestelling API goed heeft gewerkt en dat de bestelling uit het systeem is verwijderd.

Testuitvoering

Laten we het testng.xml bestand bijwerken en dit testscenario aan het einde toevoegen, na de verwijderingstest.

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">

<suite name="Restful ECommerce Test Suite">

    <test name="Testing Happy Path Scenarios of Creating and Updating Orders">

        <classes>

            <class name="io.github.mfaisalkhatri.api.restfulecommerce.HappyPathTests">

                <methods>

                    <include name="testShouldCreateNewOrders"/>

                    <include name="testShouldDeleteTheOrder"/>

                    <include name="testShouldNotRetrieveDeletedOrder"/>

                </methods>

            </class>

        </classes>

    </test>

</suite>

Nu zouden alle drie de tests opeenvolgend moeten worden uitgevoerd. De eerste zal bestellingen creëren; de tweede zal de bestelling met order_id “1” verwijderen; en de laatste test zal de GET API aanroepen om de bestelling met order_id “1” op te halen, wat Statuscode 404 retourneert.

De screenshot hierboven toont aan dat alle drie de tests succesvol zijn uitgevoerd en dat de DELETE API goed heeft gewerkt zoals verwacht.

Samenvatting

DELETE API-aanvragen staan de verwijdering van de resource uit het systeem toe. Aangezien verwijdering een belangrijke CRUD-functie is, is het belangrijk om dit te testen en te verifiëren dat het systeem werkt zoals verwacht. Het moet echter worden opgemerkt dat DELETE een onomkeerbaar proces is, dus het moet altijd met voorzichtigheid worden gebruikt.

Naar mijn ervaring is het een goede aanpak om de GET API aan te roepen na het uitvoeren van het DELETE-verzoek om te controleren of de opgegeven bron succesvol uit het systeem is verwijderd.

Veel succes met testen!