Test strategies in microservices.

1. Mesut ÖZEN
Software Developer
@mstzn36
https://github.com/mesut/test-practice

2. • Pros
• Independent Scability
• Independent/Parallel Deployment
• Tech Agnostic
• Cons
• Increased Complexity Problem with Data Consistency
• Hard to maintenance
• Orchestration
Single Responsibility at the architecture level

3. Continuous Delivery is the ability to get changes of all types—including new features,
configuration changes, bug fixes and experiments—into production, or into the hands of
users, safely and quickly in a sustainable way(*)
* https://continuousdelivery.com/ -Jez Humble
• Faster time to
market
• Higher Quality
• Lower Costs
• Happier People

4. How do you know that your latest change still results in releasable software?
• Time-consuming
• Repetitive and boring work
• Leads mistake
Traditionally testing?
Code Done Auto
Automated
Testing
Auto Staging Auto
Automated
Testing
Manuel
Deploy to
Production
Use build pipelines to automatically and reliably get your software into production

5. * http://laraveldaily.com/automated-testing-6-open-source-laravel-projects/

6. https://martinfowler.com/bliki/TestPyramid.html
Write tests with different granularity
The more high-level you get the fewer tests you should have

7. Controllers
Service Layer
Repositories
Domain
Data Mappers
Datastore
HttpClient
AmqpClient
ExternalService
Message Broker
Network Boundary
Logical Boundary

8. https://martinfowler.com/articles/practical-test-pyramid.html

9.  Junit as our test runner
 Mockito for mocking dependencies
 Wiremock for stubbing out third-party services
 MockMVC fir writing HTTP integration test
 Pact for writing CDC tests
 Selenium for writing UI-driven end-to-end tests
 REST-assured for writing REST API-driven end-to-end test

10. Testing smallest piece of software
whether determine behaves as expected
or notSolitary : Heavy usage of Test
Doubles
• Dummy
• Stub
• Mock
• Spy
• Fake
Solidatary : Use real objects
if you can
Controllers
Service Layer
Repositories
Domain
Data Mappers

11. • Test first makes design better
• Cover all edge cases
• Not to close to production code
• Don’t worry about private. Just public
interface
• Trivial code? Forget it

12.  How about integrate with other parts
(db,network calls,filesystem)
 Live at the boundary of your service
 Test Double
 Where you either serialize or deserialize data

13.  Testing the user interface of your application works
correctly
 No need to be end-to-end testing
 Multiple aspects that we want to test.
(behaviour,usability,layout)
 Unit testing for behaviour of UI

14. Common interfaces between microservices
• Rest via Http
• gRpc
• event driven
Provider serves data to consumers
Consumer processes data from provider

15. Consumer –Driven Contact tests
Consumer drives the implementation of contract
• Postel’s law
- Consumer team writes tests and publish it to provi
- Providing team now can develop their API by runni
Pact can be used

16. Biggest confidence whether software working or not as expected
Often fail for unexpected and unforseeable reasons
Pretty slow and and need a lot of maintenance

17.  Write as few end-to-end tests as possible
 Choose your ends wisely
 Data is not centralized
 Should be unique across test suite
 Deletes only the data is created

18. Even the most diligent test automation efforts are not perfect
Can miss edge cases in automated tests
The tester’s freedom and creativity to spot quality issues
Great feedback for maturating build pipeline

19. Exploratory
E2E
Contract
Integration
Unit

20. Any Questions?