This is a session given by Michael Kuehne at Nordic APIs 2016 Platform Summit on October 26th, in Stockholm Sweden. Description: It can be tough to test an apparently simple service comprehensively. A microservice architecture brings a new level of complexity to the question “How can we validate that our API is working as intended?” In this talk Michael will explain how to use test driven development for APIs and even further how TDD can drive an API Design towards a more usable design, and how to build an well-tested ecosystem of microservices. This approach is applicable for different kinds of services (REST APIs, websockets, industrial protocols). Independent from the type of interface we always ran into similar problems when we build an ecosystem of services. We have to deal with dependency, asynchronous behaviours, fallback mechanisms, endpoint versioning and sometimes even shared databases. It’s not trivial to apply TDD to these kinds of problems cause you have to think of scenarios. But there are ways of identify these scenarios and to test them. As an API specialist Michael worked with various clients designing, building, testing, maintaining and even redesigning private and public services. Based on his project experience he developed a practical approach to apply TDD to APIs in microservice ecosystems.

1. @michikuehne
TDD for APIs
in a Microservice World
Michael Kuehne-Schlinkert
Head of Development @ Cybus

2. @michikuehne
Cybus brings untapped Data Sources to a secure API
Access Control
Pre-Processing & API
Shopfloor Protocols
Security
Monitoring
Maintenance
Efficiency
Sovereignty

3. @michikuehne
Our Challenges
Security, Reliability & Scalability è Service Level Agreements
Better Representation of Customer Needs through Tests & Codes
Loosly coupled but highly connected Microservices
Efficient TDD with limited resources

4. @michikuehne
„How to validate that our API is working
as intended?“
by Steve Klabnik

5. @michikuehne
„How to efficiently validate that our
microservice ecosystem is working as
intended?“
by Michael Kuehne-Schlinkert

6. @michikuehne
Simplified Ecosystem
Device
Service
Data {...}
Data{...}
Data{...}
UI
Service
Auth
Service

7. @michikuehne
Where to start?
Story
As a <role>,
__.I want <feature>
__.so that <reason>.
Example
__.As an admin of the cybus middleware
__.I want to control the read access to my devices
__.so that users can only read the data they are allowed to
Scenario
GIVEN <context>
__.WHEN <event>
__.THEN <outcome>
Example
__. GIVEN External Device
__. GIVEN Device Service
__. GIVEN Auth Service
__. WHEN External Device provides new data
__. WHEN Read Access to Device is granted
__. THEN Device Service reads data from external device

8. @michikuehne
Test Scenario
Device
Service
Data {...}
Data{...}
Data{...}
UI
Service
Auth
Service
External
Device
Data{...}
Stubbed

9. @michikuehne
Acceptance Tests
Platform Tests
Turn Scenarios into Tests
Focus on whole Microservice Ecosystem
Verify Functionality of Ecosystem
External / Third-Party Services are stubbed/mocked
Black Box Testing
Entry Point of Platform Test depends on Scenario
API
GUI
Contract Tests
Turn API Specifications into Tests
Focus on only One Mircroservice
Verify the Interface (Contract)
Black Box Testing

10. @michikuehne
Integration Tests
A.k.a. Component Tests & Service Tests
Focus on only One Microservice
Verify Functionality of One Service
Break down Scenarios
End-to-End Tests – but not to end of ecosystem
Internal Services are stubbed/mocked
Gray Box Testing (Black & White)
Resources
Domain
ORM
External
Client
Stubbed
Service
Ext. DB
Stb.
Test
Client
Simplified
Microservice
Architecture

11. @michikuehne
Functional Tests
Controller
Industrial
Protocol
Device
Handler
Focus on 2+ Classes/Modules of Domain
Verify Interaction between Modules
White Box Testing
Internal Dependencies are stubbed/mocked
Example
Domain of
Microservice
Stubbed

12. @michikuehne
Unit Tests
Controller
Industrial
Protocol
Device
Handler
Focus on One Unit (Class/Module) of Domain
Verify Functionality of One Unit
Internal Dependencies are stubbed/mocked
White Box Testing
Example
Domain of
Microservice
Stubbed

13. @michikuehne
Our TDD Cycle
Acceptance
Tests
Integration
Tests
Functional
Tests
Unit
Tests
Code
Black Box
Gray Box
White Box

14. @michikuehne
Our TDD Cycle with aspired Test Coverage
Acceptance
Tests
Integration
Tests
Functional
Tests
Unit
Tests
Code
tcU à 100%
tcI à 100%
tcF à 100% - tcI
tcI + tcF à 100%
tcA à x%
tc = test coverage
x
–

15. @michikuehne
Lessons Learned
It works! We overcame Testing Hell
Less Test Code and less Fragile Tests but high test coverage
Quality of Story Definitions increased with mandatory Scenarios
Efficency comes with the right Tools
Each Microservice must provide Test Library (e.g. Stubs)
Deterministic Environments gained Complexity
Asynchronous Services require Gray to White Box Testing
Functional Tests became our Plan B

16. @michikuehne
cybus.io
@cybus_io
hello@cybus.io
Pssst! We‘re hiring!
Michael Kuehne-Schlinkert
@michikuehne
kuehne@cybus.io
Thx! ...and happy testing!

17. @michikuehne
Appendix
Icons by Gregor Cresnar from www.flaticon.com is licensed by CC 3.0 BY
Icons by Freepik from www.flaticon.com is licensed by CC 3.0 BY