Struggling to test failure cases like receiving an invalid response , 5XX errors and so on? Having flaky tests due to slow API responses?

Blocked because the API you depend on doesn't exist yet or isn't completely ready? Facing trouble to test various scenarios due to lack of control over third-party APIs?

These are some very common problems we encounter. We cannot rely on slow APIs, which provide a very narrow range of responses. So how can we test effectively  in such situations? Is there any feasible solution available? Fortunately, there is: mocking of APIs.

If you are less familiar with mocks & want to gain more insight, join this talk.

In this session, I will explain how to mock APIs using Wiremock. With real life example application, we'll explore how  to handle complicated scenarios and formtesting strategy. Join this session to gain insights on how, when, and most importantly why we should mock APIs. Let's find together how development and testing can benefit from mocks. Remember, 'If API testing is the king, mocking APIs is the queen!'

Please note: At the end of this talk, all attendees will get access to the example application used during talk for trying out the mocking themselves.

Target Audience: Developers, testers, test managers, decision maker
Prerequisites: Basic Knowledge of APIs
Level: Advanced

Immer häufiger wird Software als verteiltes System mittels Microservices umgesetzt. Während der Programmcode je Service dabei kompakter und leichter testbar ist, werden die Schnittstellen untereinander eher komplexer und schwer zu testen. Allzu oft werden API Tests vernachlässigt, was zu erhöhter Fehleranfälligkeit und schlechtem API Design führt.

Dieser Vortrag zeigt mit einem Augenzwinkern und anhand praktischer Beispiele, welche Fehler sich besonders dazu eignen, APIs aufgrund falscher oder fehlender Tests zu ruinieren. Er soll zum Nachdenken anregen, was man beim API Design und Test in verteilten Systemen alles bedenken sollte.

Zielpublikum: Tester, Entwickler, Architekten
Vorraussetzungen: REST/Messaging APIs, Microservices, Testautomatisierung
Schwierigkeitsgrad: Basic

Extended Abstract:
Immer häufiger werden Softwaresysteme heutzutage als auf Microservices basierende, verteilte Systeme designt, welche sich an den Bounded Contexts der Domäne orientieren. Dabei bringt dieser Architekturansatz neben vielen Vorteilen, wie der leichteren Änderbarkeit einzelner Services und unabhängigerer Entwicklung, auch Herausforderungen durch den höheren Verteilungsgrad mit sich. Ohne Kommunikation zwischen den Services über entsprechende Schnittstellen (APIs) geht es letztlich auch nicht.

Dabei gestaltet sich das Testen jener APIs nicht als trivial, sowohl technologisch als auch aus prozessualen Gesichtspunkten. Schnell wird zum Beispiel der Ruf laut nach integrativen Testumgebungen zur Integration der Schnittstellen. Jedoch widerspricht genau dies der losen Kopplung, die man durch Microservices erreichen wollte.

Dieser Vortrag zeigt mit einem Augenzwinkern und anhand praktischer Beispiele, wo typische Fehlerquellen beim API Testing in verteilten Anwendungen lauern und wie man das Softwaresystem dadurch bestmöglich in den Ruin stürzen kann. Er soll zum Nachdenken anregen, was man beim API Design und Test in verteilten Systemen alles bedenken sollte, um Qualität und Unabhängigkeit zu erhalten.