Fake it until you `make it` API integration testing with WireMock and Testcontainers By Oleg (2x)
Testcontainers has become one of the most popular tools for software integration testing. If you can put your system-under-test into a container, Docker compose cluster or a pod, this is what you're likely to use. If your target isn't ready, not containerizable or just too heavy for testing as is, you can always use mock API testing frameworks like WireMock. Can you combine both approaches? Sure!
In this talk, we will classify integration testing and discuss application areas for WireMock and Testcontainers, and discuss which tool to choose for each use-case. And why not both? We will discuss putting WireMock into Testcontainers, and getting the best from their features thanks to the new modules and integrations. Last but not least, we will see how to put WireMock in front of the Testcontainers or your real system to do deeper tests or even chaos engineering.
P.S: We will focus on the Java and maybe Golang examples, but the same approaches can be used in any technology stack for which the Testcontainers SDK is available.
OLEG NENASHEV
Oleg is a developer tools hacker, community builder and consultant currently working on WireMock and WireMock Cloud ecosystems. He's passionate open source software and open hardware advocate. Oleg is a core maintainer and board member in the Jenkins project where he writes code, mentors contributors and organizes community events. He is a TOC member in the Continuous Delivery Foundation, and also a CDF and CNCF ambassador. Oleg has a PhD degree in electronics design and volunteers in the Free and Open Source Silicon Foundation.
OLEG ŠELAJEV
Oleg Šelajev is a developer advocate at AtomicJar working on making integration tests with Testcontainers better for everyone in the community. VirtualJUG leader. Java Champion.
Пікірлер: 3
Oleg is making me a better java developer everyday, thanks Devoxx.
Introductory talk for junior-level developers
31:34 I dont see relation here. CDD (Contract driven development) relies on the contract (API spec) created/edited before you even start to develop/change the service. In perfect implementation you create a an API spec or change in it and tests (both "happy paths" and "bad paths") should be generated from this spec. And now developer should adapt his code to the spec . If he does not do that - for example he pushes the branch just with an updated spec, nothing else, to repository - then CI pipeline wich will run those newly generated tests against service built from "old"/not-adapted code will fail. So importing spec (OpenAPI preferably), building a mocks from it and generating tests from it are key features here. Recreating the API by recording (along with exporting spec in OpenAPI format) would be usefull only once - when you want to build your spec from scratch for already existing system.