1. What’s the best approach to
TDD?
Luca Ferrari
EMEA SSA for API
Management
Sergio Gutierrez Romero
EMEA SSA for API
Management
2
2. CONFIDENTIAL INTERNAL USE2019 RED HAT TECH EXCHANGE
4
What can you expect during this session:
➔ Introductions
➔ Context
➔ TDD foundations
➔ Tools
➔ Stub, Mock, Service Virtualization
➔ API contract first approach
➔ Key takeaways
➔ Where next
4. CONFIDENTIAL INTERNAL USE2019 RED HAT TECH EXCHANGE
Introductions
6
Name:
Luca Ferrari
Role/team:
EMEA SSA
Where you’re from:
Barcelona & Pavia
Name:
Sergio Gutierrez Romero
Role/team:
EMEA SSA
Where you’re from:
Barcelona
7. CONFIDENTIAL INTERNAL USE2019 RED HAT TECH EXCHANGE
9
Agile Integration foundations
DISTRIBUTED
INTEGRATION
CONTAINERS APIs
LIGHTWEIGHT
PATTERN BASED
EVENT-ORIENTED
COMMUNITY-SOURCED
CLOUD-NATIVE SOLUTIONS
LEAN ARTIFACTS, INDIVIDUALLY
DEPLOYABLE
CONTAINER-BASED SCALING & HIGH
AVAILABILITY
WELL-DEFINED, REUSABLE, &
WELL-MANAGED
ENDPOINTS
ECOSYSTEM LEVERAGE
API
SERVICES
SECURITY, AUTHENTICATION, AUDIT (RH-SSO)
RED HAT
FUSE
RED HAT
AMQ
8. CONFIDENTIAL INTERNAL USE2019 RED HAT TECH EXCHANGE
10
Red Hat API Lifecycle
3. MOCK
4. TEST
5. IMPLEMENT
6. DEPLOY
7. SECURE
8. MANAGE
9. DISCOVER
10. DEVELOP
11. CONSUME
12. MONITOR
13. MONETIZE
1. STRATEGY
2. DESIGN
9. CONFIDENTIAL INTERNAL USE2019 RED HAT TECH EXCHANGE
11
Red Hat API Lifecycle
Microcks
MOCK
TEST
IMPLEMENT
DEPLOY
SECURE
M
ANAGE
DISCOVER DEVELOP
CONSUME
MONITOR
MONETIZE
API Model Canvas
STRATEGY
DESIGN
SINGLE SIGN-ON (SSO)
12. CONFIDENTIAL INTERNAL USE2019 RED HAT TECH EXCHANGE
14
TDD Foundations
“Best of” software testing:
● No test at all (!!!)
● Manual tests
● Automated tests on customer irrelevant scenarios
● Automated tests introduced late in the process
● Test are dedicated leftover time
● Lack of communication in the team
● No code refactoring because:
○ Software will break
○ Cost will be too high
○ Software will not be delivered on time
○ Software is not documented
● Cannot rely on test phase for production
● Long regression tests
13. CONFIDENTIAL INTERNAL USE2019 RED HAT TECH EXCHANGE
15
TDD Foundations
Test Driven Development is a simple procedure of writing tests before the implementation.
In practice a repetition of a very short development cycle:
1. Write a test.
2. Run all tests.
3. Write the implementation code.
4. Run all tests.
5. Refactor.
6. Run all tests.
14. CONFIDENTIAL INTERNAL USE2019 RED HAT TECH EXCHANGE
16
TDD Cycle
REFACTOR
Eliminate
redundancies
RED
Write a test that fails
GREEN
Make the code work
TDD
15. CONFIDENTIAL INTERNAL USE2019 RED HAT TECH EXCHANGE
17
TDD Foundations
Software testing
White-box testingBlack-box testing
16. CONFIDENTIAL INTERNAL USE2019 RED HAT TECH EXCHANGE
MOCKING:
If it can be easily mocked then it is well structured
EXECUTABLE DOCUMENTATION:
Main problem with software documentation is not up to date and inevitably gets outdated.
Assuming that Continuous Integration (CI) is in use, if some part of test-documentation is
incorrect, it will fail and be fixed
If all functionality is defined as tests before the implementation and execution of all tests is
successful, then tests act as a complete and up-to-date information
NO DEBUGGING:
When tests are written before the code and the code coverage is high, we can have high
confidence that the application works as expected. This does not mean that applications
written using TDD do not have bugs, all applications do. When that happens, it is easy to
isolate them by simply looking for the code that is not covered with tests.
18
TDD Cycle
17. CONFIDENTIAL INTERNAL USE2019 RED HAT TECH EXCHANGE
19
TDD Cycle
Don’t want test to focus on external components
Don’t want to add external dependencies to my code
Want to find the defect fast
Want to make the test predictable
Want the test to be fast (fail or succeed)
.
.
.
.
.
BUT eventually I will want to have an integration test covering corner conditions as well
Mocking Phase
19. CONFIDENTIAL INTERNAL USE2019 RED HAT TECH EXCHANGE
21
TDD Tools
Several tools can be helpful for the specific purpose of TDD:
● Git
● Virtual machines / containers
● Build tools
● Integrated Development Environment
● Unit testing frameworks
● Code coverage tools
● Mocking frameworks
● User interface testing
● Behavior-Driven Development
20. CONFIDENTIAL INTERNAL USE2019 RED HAT TECH EXCHANGE
22
TDD Tools
Several tools can be helpful for the specific purpose of TDD:
● Git
● Virtual machines / containers
● Build tools
● Integrated Development Environment
● Unit testing frameworks
● Code coverage tools
● Mocking frameworks
● User interface testing
● Behavior-Driven Development - Cucumber
Agile process where the requirement is written so
that everyone (business or developer) understands
it. Requirements are grouped in user stories.
Stories are written by the whole team and used as
both requirements and executable test cases. It
allows to describe and test functionality in (almost)
natural language and makes it runnable and
repeatable.
22. CONFIDENTIAL INTERNAL USE2019 RED HAT TECH EXCHANGE
24
Design phase
If it's not testable, it's not designed well
Principles:
● You Ain't Gonna Need It (YAGNI)
● Don't Repeat Yourself (DRY)
● Keep It Simple, Stupid (KISS)
● Occam's Razor
● SOLID Single responsibility principle
Open-closed principle
Liskov substitution principle
Interface segregation principle
Dependency inversion principle
25. CONFIDENTIAL INTERNAL USE2019 RED HAT TECH EXCHANGE
27
Stub VS Mock VS Virtual Service
Stub: a minimal implementation of an interface that normally returns hardcoded data that is
tightly coupled to the test suite. A stub is normally written by a developer for personal use
Mock: a programmable interface observer, that verifies outputs against expectations
defined by the test. Mock provides responses based on a given request satisfying
predefined criteria (also called request or parameter matching). A mock also focuses on
interactions rather than state so mocks are usually stateful.
Virtual service: a test double, always called remotely. A virtual service is often created by
recording traffic instead of building the interaction pattern from scratch based on interface
or API documentation. A virtual service can be used to establish a common ground for teams
to communicate and facilitate artifact sharing with other development teams. It can also
simulate non-functional characteristics of systems such as response times or slow
connection
26. CONFIDENTIAL INTERNAL USE2019 RED HAT TECH EXCHANGE
28
Stub VS Mock VS Virtual Service
STUB MOCK VIRTUAL SERVICE
Data source Hardcoded data Data setup by tests Recorded data
Invocation protocol Usually in the same process,
sometimes over HTTP or TCP
Most of the time over HTTP or
TCP
Always over the network
Created by Devs and sometimes testers Devs and sometimes testers Mostly testers
Stateful No Yes Yes
28. CONFIDENTIAL INTERNAL USE2019 RED HAT TECH EXCHANGE
30
Stubbing
Anybody fancy a
popular mock framework which can be used in conjunction with JUnit. Allows you to create
and configure mock objects. Simplifies the development of tests for classes with external
dependencies.
● Mock away external dependencies and insert the mocks into the code under test
● Execute the code under test
● Validate that the code executed correctly
29. CONFIDENTIAL INTERNAL USE2019 RED HAT TECH EXCHANGE
31
@Entity
public class Customer {
@Id
@GeneratedValue(strategy =
GenerationType.AUTO)
private long id;
private String firstName;
private String lastName;
//...getters and setters redacted for
brevity...
}
public class CustomerReader {
@PersistenceContext
private EntityManager entityManager;
public String findFullName(Long customerID){
Customer customer =
entityManager.find(Customer.class, customerID);
return customer.getFirstName() +"
"+customer.getLastName();
}
}
30. CONFIDENTIAL INTERNAL USE2019 RED HAT TECH EXCHANGE
32
public class CustomerReaderTest {
//Class to be tested
private CustomerReader customerReader;
//Dependencies
private EntityManager entityManager;
@Before
public void setup(){
customerReader = new CustomerReader();
entityManager = mock(EntityManager.class);
customerReader.setEntityManager(entityManager);
}
@Test
public void happyPathScenario(){
Customer sampleCustomer = new Customer();
sampleCustomer.setFirstName("Susan");
sampleCustomer.setLastName("Ivanova");
when(entityManager.find(Customer.class,1L)).thenReturn(sampleCustomer);
String fullName = customerReader.findFullName(1L);
assertEquals("Susan Ivanova",fullName);
}
@Test
public void customerNotPresentInDb(){
when(entityManager.find(Customer.class,1L)).thenReturn(null);
String fullName = customerReader.findFullName(1L);
assertEquals("",fullName);
}
}
32. CONFIDENTIAL INTERNAL USE2019 RED HAT TECH EXCHANGE
34
Mocking
Multi-type of Services / API
support
Usable by functional experts,
comprehensive UI
Mock support and ability to deploy
at scale
Ability to use specifications for
running tests
http://microcks.github.io
33. CONFIDENTIAL INTERNAL USE2019 RED HAT TECH EXCHANGE
35
Mocking
Service
Contract
Service
Consumer
Development
Test &
Release
Specification
Service
Provider
Build and deploy your
Services / API mocks for
you !
CI / CD
Use mocks for external
dependencies for easier Integration
Testing
34. CONFIDENTIAL INTERNAL USE2019 RED HAT TECH EXCHANGE
36
Mocking
Service
Contract Development
Test &
Release
Service
Provider
Test your deployed services and
validate expectations
CI / CD Pipeline
QADev
Smoke tests, Functional tests on
different environments. Record
exchanges for tracking differences.
36. 2019 RED HAT TECH EXCHANGE
38
Service
Virtualization
37. CONFIDENTIAL INTERNAL USE2019 RED HAT TECH EXCHANGE
39
Service virtualization
Predicting the Unpredictable!
Mock APIs
TESTING PREDICTABLE MODEL
Test cases Mock APIs
TESTING THE UNPREDICTABLE
Network Latency
Partial Outage and Cascading
failures
Traffic Spikes
38. CONFIDENTIAL INTERNAL USE2019 RED HAT TECH EXCHANGE
40
Service virtualization
Imitation of the REAL API or Mocking on Steroid
Best practices:
1. Use realistic data
2. Isolate API methods
3. Test various response and error codes
4. Simulate network condition and server capacity
5. Do the load on virtual APIs (first)
39. CONFIDENTIAL INTERNAL USE2019 RED HAT TECH EXCHANGE
Can everything be virtualized?
41
Service virtualization
https://www.networkworld.com/article/2344791/kellogg-s--lego-team-up-to-trai
n-kids-to-choke.html
45. CONFIDENTIAL INTERNAL USE2019 RED HAT TECH EXCHANGE
Microservice
architecture
48
API Contract First
Moving to Agile
development
Speed of
development
Quality affected
Need automated
testing
TDD approach
API Contract
First
47. CONFIDENTIAL INTERNAL USE2019 RED HAT TECH EXCHANGE
50
Key takeaways
❏ Know the difference between stub, mock and service virtualization
❏ Understand the advantages of TDD and API-contract-first approaches
❏ Know which Open Source tools can be used
48. CONFIDENTIAL INTERNAL USE2019 RED HAT TECH EXCHANGE
51
Resources
Go, use and contribute to Microcks: http://microcks.github.io/
Roadmap themes for Microcks:
● Tekton integration
● Better integration with APICURIO
● Async API support
We have Microcks customers as well:
● Societe Generale
● EDF
Try Day In a Life workshop: https://mojo.redhat.com/docs/DOC-1189138
As reference for most of the content I used this book:
https://www.amazon.com/Test-Driven-Java-Development-Viktor-Farcic-ebook/dp/B00YS
IM3SC