Naresh will be presenting the following session
filter_list help_outline
  • Naresh Jain
    Naresh Jain
    schedule 1 year ago
    Sold Out!
    45 Mins

    In a complex, interdependent eco-system, where each service is evolving rapidly, we typically end up with an Integration Hell .i.e. the myriad problems that occur when API integrations break down

    • Provider and consumer integrations break when their understanding of the API endpoints are out of sync
    • Working integrations break when the API developer makes a change without informing the consumer
    • Development and testing slow down when the consumer depends on the provider API running in a staging environment:
      • The network may be down
      • The environment hosting the API may be down
      • The staging API may crash, or may not even be started
      • Development can be delayed if the staging API is not kept up-to-date
      • API changes can come in at the last minute, resulting in breakage on the consumer side
      • The provider API may break backward compatibility, resulting in breakage on the consumer

    Instead, what if we could make the dependencies between the provider and consumers explicit in the form of executable contracts. These executable contracts provide a common, clear definition of their API endpoints. They give instantaneous feedback about accidental breakage to the teams so that they can work independently. These executable contracts are:

    1. Kept up-to-date and acts as a single source of truth
    2. Used for service virtualisation, keeping consumers in sync with the contract
    3. Run as tests against the provider API to validate it's request and response type definitions
    4. Tightly integrated with CI
    5. Capable of pinpointing any backwards-incompatible changes to the contract

    This is Contract Driven Development, and it heralds the Death of Integration Hell.

    Here's a sample contract:


    This session will demonstrate all the key points of Contract Driven Development as implemented by the teams using an open-source tool called Specmatic.

1. What got you started/interested in Agile?

Back in 2002, I used to work for a German Bank. Our product's Architect insisted that we must share passing automated tests every time we initiated a code review. Every time I wrote automated tests, I found stupid mistakes I had made. It was very frustrating! So I started looking for a better way.

I stumbled upon the "Test Infected: Programmers Love Writing Tests" paper by Kent Beck. This started my journey into the world of eXtreme Programming.

2. What do you think is the biggest challenge faced by the Agile community today?

Perfection of means and confusion of goals.

The community is focusing too much on formal, well-defined frameworks and certifications (something the agile movement was trying to avoid to start with) instead of embracing uncertainty. 

3. Tell us about the session(s) you will be presenting at the conference and why did you choose those topics?

I'll be presenting a new contract testing framework, which I've been building and using at a really large scale platform/s. 

Microservices architecture is everywhere. One of the goals of architecting your system in this style is to allow individual services to deploy at will, independently of other dependent services. However this is only possible if we've some mechanism to ensure as new versions of the service are rolled out, other dependent services are not affected. 

This is exactly what I want to demonstrate in my session.

4. What are some of the key takeaways from your session(s) at Agile India?
  • Learn how to define better contracts between two components (services)
  • Discover how to capture those contracts as executable specs
  • Understand the role of a broker in the contract tests
  • Understand how contract tests can prevent the provider from accidentally breaking the consumer