Java Day Kharkiv - Integration Testing from the Trenches Rebooted

INTEGRATION TESTING
FROM THE TRENCHES
REBOOTED
@NICOLAS_FRANKEL

ME, MYSELF AND I
https://leanpub.com/integrationtest/
2

FROM THE BOOK
3

INTRODUCTION
INTEGRATION TESTING FROM THE TRENCHES - REBOOTED
4

TESTING?
Unit Testing
Mutation Testing
GUI Testing
Performance Testing
• Load Testing
• Stress Testing
• Endurance Testing
Security Testing
etc.
5

UNIT VS. INTEGRATION TESTING
Unit Testing
• Testing a unit in isolation
Integration Testing
• Testing the collaboration of
multiple units
6

EXAMPLE
A prototype car
7

UNIT TESTING
Akin to testing each nut
and bolt separately
8

INTEGRATION TESTING
Akin to going on a test
drive
9

UNIT + INTEGRATION TESTING
Take a prototype car on a
test drive having tested
only nuts and bolts?
Manufacture a car having
tested nuts and bolts but
without having tested it on
numerous test drives?
10

SYSTEM UNDER TEST
SUT is what get tested
Techniques from Unit
Testing can be re-used
• Dependency Injection
• Test doubles
11

REMINDER: TEST DOUBLES
Dummy
Mock
Stub
Spy
Fake
12

TESTING IS ABOUT ROI
The larger the SUT
• The more fragile the test
• The less maintainable the
test
• The less the ROI
13

Tests have to be
organized in a certain way
• The bigger the SUT
• The less the number of
tests
14

Integration Testing
• Test nominal cases
15

INTEGRATION
TESTING
CHALLENGES
16

INTEGRATION TESTS CHALLENGES
Slow
Fragile
Hard to diagnose
17

Y U SLOW?
Use infrastructure
resources
Use container
18

COPING WITH SLOWNESS
Separate Integration
Tests from Unit Tests
19

INTEGRATION TESTS ARE STILL SLOW
Separating IT doesn’t
make them faster
But errors can be
uncovered faster
• Fail fast
• It will speed testing
20

HOW TO SEPARATE?
Depends on the build
tool
• Ant
• Maven
• Gradle
• Something else?
21

REMINDER: MAVEN LIFECYCLE
22

MAVEN SUREFIRE PLUGIN
Bound to the test
phase
Runs by default
• *Test
• Test*
• *TestCase
23

MAVEN FAILSAFE PLUGIN
“Copy” of Surefire
Different defaults
• *IT
• IT*
• *ITCase
24

MAVEN FAILSAFE PLUGIN
One goal per lifecycle phase
• pre-integration-test
• integration-test
• post-integration-test
• verify
Must be bound explicitly
25

POM SNIPPET
<plugin>
<artifactId>maven-failsafe-plugin</artifactId>
<version>2.17</version>
<executions>
<execution>
<id>integration-test</id>
<goals>
<goal>integration-test</goal>
</goals>
<phase>integration-test</phase>
</execution>
<execution>
<id>verify</id>
<goals>
<goal>verify</goal>
</goals>
<phase>verify</phase>
</execution>
</executions>
</plugin>
26

CONTINUOUS INTEGRATION
Unit Tests run at each
commit
Integration Tests run
“regularly”
• Daily
• Hourly
• Depending on the context
27

Y U FRAGILE?
Usage of infrastructure
resources
• External
• Multiple
28

INFRASTRUCTURE RESOURCES
File system
Time
Databases
Web Services
Mail servers
FTP Servers
etc.
29

TIME/FILE SYSTEM:
COPING WITH FRAGILITY
30
Use Dependency
Injection
Use abstractions
• e.g.
java.nio.file.Path
instead of
java.util.File

DATABASES:
31
Test the Service layer
• Mock the repository
Test the Repository
layer
• Mock the database???

DATABASES:
Use Fakes under your
control
32

ORACLE DATABASE USE-CASE
33
Use an in-memory data
source and hope for the best
Use Oracle Express and hope
for the best
Use a dedicated remote
schema for each developer
• And your DBAs will hate you

TRADE-OFF
34
The closer to the “real”
infrastructure,
the more complex the
setup

MANAGING THE GAP RISK
35
In-memory databases
are easy to setup
h2 is such a database
• Compatibility modes for
most widespread DB
• jdbc:h2:mem:test;
MODE=Oracle

WEB SERVICES:
36
Web Services as
infrastructure resources
• Hosted on-site
• Or outside
Different architectures
• REST(ful)
• SOAP

WEB SERVICES:
Use Fakes under your
control
37

FAKE RESTFUL WEB SERVICES
38
Spark
• Micro web framework
• A la Sinatra
• Very few lines of code
• Just serve static JSON files

SPARK SAMPLE
import static spark.Spark.*;
import spark.*;
public class SparkSample{
public static void main(String[] args) {
setPort(5678);
get("/hello", (request, response) -> {
return "Hello World!";
});
get("/users/:name", (request, response) -> {
return "User: " + request.params(":name");
});
get("/private", (request, response) -> {
response.status(401);
return "Go Away!!!";
});
}
}
39

FAKE SOAP WEB SERVICES
40
Possible with Spark
• But not efficient
• Remember about ROI

SMARTBEAR SOAPUI
41

SMARTBEAR SOAPUI
Has a GUI
Good documentation
Understands
• Authentication
• Headers
• Etc.
42

SOAPUI USAGE
Get WSDL
• Either online
• Or from a file
Create MockService
• Craft the adequate response
Run the service
Point the dependency to
localhost
43

CHALLENGES TO THE PREVIOUS SCENARIO
Craft the adequate response?
• More likely get one from the real WS
• And tweak it
Running in an automated way
• Save the project
• Get the SOAPUI jar
• Read the project and launch

SOAPUI API
WsdlProject project = new WsdlProject();
String wsdlFile = "file:src/test/resources/ip2geo.wsdl";
WsdlInterface wsdlInterface =
importWsdl(project, wsdlFile, true)[0];
WsdlMockService fakeService =
project.addNewMockService("fakeService");
WsdlOperation wsdlOp =
wsdlInterface.getOperationByName("ResolveIP");
MockOperation fakeOp =
fakeService.addNewMockOperation(wsdlOp);
MockResponse fakeResponse =
fakeOp.addNewMockResponse("fakeResponse");
fakeResponse.setResponseContent(
"<soapenv:Envelope ...</soapenv:Envelope>");
runner = fakeService.start();
45

FAKING WEB SERVICE IN REAL-LIFE
Use the same rules as for UT
• Keep validation simple
• Test one thing
Keep setup simple
• Don’t put complex logic
• OK to duplicate setup in each
test
• Up to a point
Author:I,rolfB
46

IN-CONTAINER
TESTING
47

INTEGRATION TESTING
48
Collaboration between
classes
Boundaries with
external dependencies
What did we forget?

DEPENDENCIES
49
The most important
dependency is the
container!
• Spring
• Java EE
• Application server

SPRING CONFIGURATION TESTING
50
So far, we can test:
• Beans whose dependencies
can be mocked
• Beans that depend on fake
resources
What about the
configuration?

DESIGNING TESTABLE CONFIGURATION
51
Configuration cannot be
monolithic
• Break down into fragments
• Each fragment contains a
set of either
• Real beans
• Fake beans

EXAMPLE: DATASOURCE CONFIGURATION
52
Production
JNDI fragment
Test in-
memory
fragment

EXAMPLE: DATASOURCE CONFIGURATION
@Bean
public DataSource ds() {
JndiDataSourceLookup lookup = new JndiDataSourceLookup();
lookup.setResourceRef(true);
return lookup.getDataSource("jdbc/MyDS");
}
@Bean
public DataSource ds() {
org.apache.tomcat.jdbc.pool.DataSource ds
= new org.apache.tomcat.jdbc.pool.DataSource();
ds.setDriverClassName("org.h2.Driver");
ds.setUrl("jdbc:h2:~/test");
ds.setUsername("sa");
ds.setMaxActive(1);
return ds;
}
53

FRAGMENT STRUCTURE
 Main fragment
• Repository
• Service
• etc.
 Prod DB
fragment
 Test DB fragment
54

TIPS
Prevent coupling
• Use top-level assembly instead
of fragment references
Pool exhaustion check
• Set the maximum number of
connections in the pool to 1
Compile-time safety
• Use JavaConfig
55

NOW, HOW TO TEST?
56
Spring Test
• Integration with
widespread testing
frameworks

SAMPLE TESTNG TEST WITH SPRING
@ContextConfiguration(
classes = { MainConfig.class, TestDataSourceConfig.class }
)
@RunWith(SpringJUnit4ClassRunner.class)
public class OrderIT {
@Autowired
private OrderService orderService;
@Test
public void should_do_this_and_that() {
orderService.order();
Assert.assertThat(...)
}
}
57

TESTING WITH THE DATABASE
Transactions
• Bound to business feature
• Implemented on Service
layer
• @Transactional
58

TRANSACTION MANAGEMENT TIP
When tests fail
• How to audit state?
• Spring rollbacks
transactions
@Commit
59

TRANSACTION MANAGEMENT SAMPLE
@ContextConfiguration
@Transactional
@Commit
@RunWith(SpringJUnit4ClassRunner.class)
public class OverrideDefaultRollbackSpringTest{
@Test
@Rollback
public void transaction_will_be_rollbacked() {
...
}
@Test
public void transaction_will_be_committed() {
...
}
}
60

END-TO-END TESTING?
61
Testing from the UI
layer is fragile
• UI changes a lot
URL not so much

MOCKMVC
62
“Main entry point for
server-side Spring MVC
test support”

MOCKMVC SAMPLE
mockMvc.perform(get("/"))
.andExpect(status().isOk())
.andExpect(view().name("welcome"));
63

SPRING BOOT
64

SPRING BOOT
65
@AutoConfigureMockM
vc
Inject MockMvc

SPRING BOOT
66
@SpringBootTest
instead of
@ApplicationContext

SPRING BOOT LAYERED TESTS
67
JPA
• @DataJpaTest
Web
• @WebMvcTest
• @MockBean

Q&A
68
http://blog.frankel.ch/
@nicolas_frankel
http://frankel.in/
https://git.io/viPPz

Java Day Kharkiv - Integration Testing from the Trenches Rebooted

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (18)

Similar to Java Day Kharkiv - Integration Testing from the Trenches Rebooted

Similar to Java Day Kharkiv - Integration Testing from the Trenches Rebooted (20)

More from Nicolas Fränkel

More from Nicolas Fränkel (20)

Recently uploaded

Recently uploaded (20)

Java Day Kharkiv - Integration Testing from the Trenches Rebooted

Editor's Notes