You are currently viewing a placeholder content from Podigee. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.
More Information
"All the interactions are mocked and a ready implementation is not needed at the point" - Mariusz Smoliński
Mariusz is an expert in Contract-Based Testing. In this interview we talk about what CBT is all about, how it solves annoying problems at integration testing and how it works in general. Mariusz shows us what consumer and producer are all about, which framework he uses and lists typical pitfalls that this way of testing brings with it.
Mariusz has been working in the IT industry for over 12 years. He started as an IT Service Desk employee in support projects for German customers in banking, industry and public sector. Almost 4 years later he switched to testing, and that's where he has stayed until today.
In England and Germany he has ensured software quality in various projects in different industries. His favorite way to work is agile. Privately, he is involved with iOs developments, among other things.
Highlights in this episode:
- Contract-based testing is particularly useful in projects with microservices and APIs
- It defines a type of contract between two parties: the provider and the user (consumer) of the interface
- PACT is one of the best-known frameworks for contract-based testing.
- Contract-based testing allows you to test the interaction with APIs at unit test level without calling the API directly
- The tests can be integrated into the CI pipeline to ensure that everything runs smoothly
- Contract-based testing promotes collaboration and helps to understand what the other party really needs from the interface
- It is important not to try to test too much with contract based testing as it is mainly intended for unit testing
- A Paktbroker helps you to always work with the latest version of the interface
Contact Mariusz:
Contract-Based Testing: A deep insight
TLDR: Discover the world of Contract-Based Testing, an innovative method for optimizing interface testing in agile projects. Learn how this method promotes collaboration and makes testing processes more efficient.
Contract-Based Testing
In my latest podcast episode, we looked at contract-based testing - an approach that is revolutionizing the testing of interfaces. This method is particularly useful in today's world, where microservices and various APIs dominate. In an insightful conversation with Mariusz Smoliński, an experienced user of contract-based testing in agile projects, we discussed the concept, its application and its many benefits. This approach not only keeps the documentation of the interface up to date, but also promotes collaboration between the teams.
What is contract-based testing?
Contract-based testing can be understood as a kind of contract between two parties: the provider and the user of an interface. All interactions are precisely defined. This process helps to optimize communication between backend and frontend or between different services within an organization. The aim is to develop and test only what the consumer really needs - a principle also known as "you aren't gonna need it".
The role of PACT as a framework
One of the best-known frameworks for supporting contract-based testing is PACT. It enables simple implementation and promotes collaboration between the parties involved. The use of a so-called pact broker allows contracts to be made easily accessible and up-to-date documentation is always available.
Contract-based testing in action
An interesting application of contract-based testing is the possibility of mocking certain interface interactions. This simplifies the testing process considerably, as there is no need to wait until the other side has completed its implementation. This method also means that only those aspects that are important to the consumer are developed and tested. This makes the development process more efficient and goal-oriented.
Limits and challenges
Despite its many advantages, there are situations where contract-based testing may not be ideal. For example, with public APIs or when there is no control over changing data. Political decisions within a project can also influence the implementation of this test method.
Concluding thoughts
The introduction of contract-based testing offers many advantages: it saves time, promotes clear communication between teams and ensures up-to-date documentation. However, it is important to know when this method is appropriate and when other tools would be more suitable. Mariusz shared valuable insights from his practical experience, making this episode a real treasure trove of information.