By: Daniel Bryant
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?
- Misses changes
- Enables local early testing
- Hoverfly
- Capture and record responses to create proxy
- Wiremock
- Mountebank
- LocalStack(AWS)
Musings
- 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)
- ”Chaos engineering”
- Principles of chaos engineering
- When things go wrong unexpectantly ==> diagnostic routines, fire drills
- Gremlin (paid)
- Tammy Butow The Path to Chaos Engineering
- High Severity Incident Management
- Monitoring
- Measure impact of downtime
Musings
- Assert system quality attributes
- Can prompt team tp think about monitoring and resilience
- Can cause a lot of damage if used wrong
Conclusion
Balance pre-production testing and production testing.
Don’t try to be absolutely correct.
Book tip: Continuous Delivery in Java