By: Daniel Bryant

Jaax direct link

Pre-prod vs post-prod tests

  • Contract testing
  • Api simulation

Test-pyramiden, agile testing quadrant

Test pyramid created before micro services, but after David Patna’s modularity ==> skilja mellan test av systemtest och mer behovsbaserad testplan för de enskilda mikrotjänsterna

Boktips: Distributed Systems Observability

Microservice test funnel – Cindy Sridharan ”testing microservices the sane way

Some tests should be done in production

Lessons learned

Unit testing

  • Don’t avoid unit test <== 77% production failues can be reproduced by a unit test
  • Testing error handling could have prevented 58% of catastrophic failures.
  • 35% of catastrophic failures because of empty error handler.

Integration/component tests

  • If it looks to complicated, it probably is
  • Coupling and cohesion apply to everything!

End to end tests

  • Representational data is often the weakest link
  • Understand your data ”shape” and volume
  • Synthetic datastores
    • Hsqldb
    • Qpid
    • Testcontainers (ramverk)

General strategies

  • Test outside-in
  • Acceptance tests for systems and services
  • ”LUFD” the context and TDD the API
  • Virtualise dependencies

Makes regressions testing easier.

JMeter vs Gatling (scala), hur påverkar det lättheten att skriva lasttester?

Synthetic transactions in production <== CAREFUL!!

Test contracts of unstable API:s. Choose your battles.

Invest in monitoring, synthetic transactions and chaos engineering (in this order).

Contract (Testing Syntax)

If you breake a contract, don’t blame, go communicate.

Usually fits between component test and end-to-end-tests.

API Contracts are service contracts

  • Many are producer driven
  • It’s possible to design outside-in
    • Consumer-driven contracts (CDC)
    • Pact (ramverk) on the Consumer side
    • Verify expectations on Provider.
  • CDC frameworks
    • Pact
    • Spring cloud contract
    • Pact supports AMQP contracts
  • Hur hantera kontrakt i t.ex. Kafka?

Contract testing Musings

  • Great in low trust low communication
    • Act as a cue for communication
  • Lesser value during incubation/startups
  • Can be used to implement TDD for the API
  • Resource intensive to create and maintain

API simulation (testing semantics)

  • How to keep track of internal services/dependencies?
  • Not always easy to mock away.
  • Virtual services?
  • LocalStack(AWS)


  • Great when service expencive to access or tricky to mock
  • Userful to test failure modes, when hard to recreate
  • Can be fragile and complicated

Fault injection (testing resilience)


  • Assert system quality attributes
  • Can prompt team tp think about monitoring and resilience
  • Can cause a lot of damage if used wrong


Balance pre-production testing and production testing.

Don’t try to be absolutely correct.

Book tip: Continuous Delivery in Java