JavaOne 2017 CON2902 - Java Code Inspection and Testing Power Tools

TOOLS
JAVA
CODE INSPECTION
AND TESTING
JAVAONE 2017
CON2902
SAN FRANCISCO - 3 OCTOBER 2017
JORGE HIDALGO
ACCENTURE DELIVERY CENTER IN SPAIN
ACCENTURE GLOBAL JAVA CAPABILITY

Copyright 2017 Accenture. All rights reserved. 2
WHO I AM
Jorge Hidalgo @_deors
Coordinator – Málaga JUG
Global Java Lead – Accenture Technology
Java, Architecture & DevOps Lead – Accenture Delivery Center in Spain
Father of two children, husband, whistle player, video gamer, sci-fi ‘junkie’,
Star Wars ‘addict’, Lego brick ‘wielder’, Raspberry Pi fan… LLAP!
https://deors.wordpress.com
https://www.meetup.com/es-ES/MalagaJUG/

CODE INSPECTION
CODE COVERAGE
MUTATION TESTING
MOCKS, STUBS, DOUBLES
SECURITY TESTING
CODE INSPECTION AND TESTING TOOLS

MOTIVATION – WHY USE TOOLS?
QUALITY
Software craftmanship
No blaming
No last minute fixes
Client satisfaction
Boss satisfaction
Pay rise!
PRODUCTIVITY
No boring, repetitive tasks
Focus on the cool stuff
Do more in less time
Client satisfaction
Boss satisfaction
Pay rise!
PREDICTABILITY
Software development as
a precision work
Always on schedule
No surprises
Client satisfaction
Boss satisfaction
Pay rise!

CODE INSPECTION
WHAT
WHY
Statically profile source code and configuration for adherence to
defined coding standards, architecture & design best practices,
and to highlight potential bugs.
Improve quality and productivity (less defects mean less fix effort).
By using tools to automate code inspection, reviews are
exhaustive and inclusive of all source files.
Let the core review effort focus on constructive conversations
about the creative aspects of the functionality and how it is
implemented.

CODE INSPECTION TOOLS
ScapegoatScalastyle

Beware of
overlapping
(equivalent)
rules!

+ plug-ins
Get the best from
each of them
Combine outputs
into a single
report
Code reviews
Action plans

CODE COVERAGE
WHAT
WHY
Measure what source code and branches are actually executed
after any suite of tests, both automated and manual.
Identify which lines and branches of application code have not
been executed by tests, and hence pinpoint which specific test
cases are missing and should be created.
Code coverage should be used as a ‘negative test’, never as a
‘positive test’.
It is not uncommon to see automated test cases that simply run
some code, without actually checking / asserting anything.

CODE COVERAGE TOOLS
CoberturaJCov
isparta

CODE COVERAGE TOOLS
Use it to gather coverage
from manual tests,
if you don’t have automated
Use EclEmma inside Eclipse
to ensure all key test cases
are covered by tests
Combine with SonarQube
listener to get metrics per
every single test executed

CODE COVERAGE TOOLS

CODE COVERAGE TOOLS
<dependency>
<groupId>org.jacoco</groupId>
<artifactId>org.jacoco.agent</artifactId>
<version>0.7.9</version>
<classifier>runtime</classifier>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.sonarsource.java</groupId>
<artifactId>sonar-jacoco-listeners</artifactId>
<version>4.11.0.10660</version>
<scope>test</scope>
</dependency>
To enable code coverage per test:
1. Add these dependencies to pom.xml

CODE COVERAGE TOOLS
To enable code coverage per test:
2. Enable JaCoCo listener in Surefire
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.20.1</version>
<configuration>
<properties>
<property>
<name>listener</name>
<value>org.sonar.java.jacoco.JUnitListener</value>
</property>
</properties>
</configuration>
</plugin>

MUTATION TESTING
WHAT
WHY
Identify uncovered test cases by executing unit tests after pieces
of code are mutated (specific, atomic changes).
Ensure that automated test code is covering all the relevant test
cases and conditions.
Code coverage is simply not enough.
Mutation testing pinpoints which tests are not asserting that
actual results are equal to expected results, as well as uncover
specific conditions that were not tested (possible even if code
coverage says 100% lines and branches are tested).

MUTATION TESTING TOOLS

Mutation testing tools
introduce controlled changes
in application code, one at a time
Code base Code mutation
if (a >= 0) if (a < 0)
if (b == 1) if (a == -1)
someObject.someMethod(“hi”) someObject.someMethod(null)
someObject.someMethod(whatever) Method call is removed
Re-execute those tests executing the modified logic
If tests do not fail, then the test is wrong
➢ It is not asserting thoroughly enough
➢ It is not asserting anything!

Key facts for the really impatient:
It does not require changes in application code
It does not require changes in test code
It requires zero or little configuration
It mutates on bytecodes, so it is as efficient as possible
It re-executes only the relevant tests after a change
Yet… it takes time!
Run Pitest in the background in your IDE, or in CI builds
publishing results to SonarQube!

Results in Eclipse
Results in SonarQube

Configure exclusions wisely, Pitest can take very long
hours to execute with integration tests
Use XML output to pull data
into SonarQube

Example mutators:
 Conditionals Boundary Mutator
 Negate Conditionals Mutator
 Remove Conditionals Mutator
 Math Mutator
 Increments Mutator
 Invert Negatives Mutator
 Inline Constant Mutator
 Return Values Mutator
 Void Method Calls Mutator
 Non Void Method Calls Mutator
 Constructor Calls Mutator

MOCKS, STUBS, DOUBLES
WHAT
WHY
Isolate automated tests from external dependencies, that may or
may not be available at the time of the test execution.
Automated tests should be repeatable, and as independent from
the execution environment and moment as possible.
By isolating external dependencies, tests are less subject to
interference, are more robust, and focused on one verification
each time. Error and exceptions can be simulated.
Using mocks, stubs and test doubles, the behavior of external
dependencies is simulated by applying different strategies.
Critical for unit tests!

MOCKING FRAMEWORKS
Spock
SINON.JS
ScalaMock

MOCKING FRAMEWORKS
EasyMock provides common mocking patterns
PowerMock is capable of instrumenting code and
make testable code that isn’t:
• static blocks
• constructors
• object instantiation
• private members
JMockit provides all capabilities above combined,
with a more modern and expressive API

MOCKING FRAMEWORKS
public class DirectoryManager {
public DirectoryManager(String directoryHost, int directoryPort)
throws DirectoryException {
super();
if (directoryHost == null || directoryHost.length() == 0 || directoryPort <= 0) {
throw new IllegalArgumentException("ERR_OPEN_CONN_ARG");
}
try {
connection = new LDAPConnection();
connection.connect(directoryHost, directoryPort);
} catch (LDAPException ldape) {
throw new DirectoryException("ERR_OPEN_CONN", ldape);
}
connected = true;
}
…
}
Constructor that opens an LDAP connection

MOCKING FRAMEWORKS
Making it testable with EasyMock + PowerMock
@RunWith(PowerMockRunner.class)
@PrepareForTest(DirectoryManager.class)
public class DirectoryManagerPowerMockTestCase {
@Test(expected = DirectoryException.class)
public void testConstructorError() throws Exception {
LDAPConnection lc = PowerMock.createMock(LDAPConnection.class);
PowerMock.expectNew(LDAPConnection.class).andReturn(lc);
lc.connect("localhost", 2000);
EasyMock.expectLastCall().andThrow(new LDAPException("error", 1, "error"));
PowerMock.replay(lc, LDAPConnection.class);
new DirectoryManager("localhost", 2000);
}
…
}

MOCKING FRAMEWORKS
Making it testable with JMockit
@RunWith(JMockit.class)
public class DirectoryManagerJMockitTestCase {
@Mocked(stubOutClassInitialization = true)
LDAPConnection connection = new LDAPConnection();
@Test(expected = DirectoryException.class)
public void testConstructorError() throws Exception {
new Expectations() {{
connection.connect("localhost", 2000);
result = new LDAPException("error", 1, "error");
}};
new DirectoryManager("localhost", 2000);
}

SECURITY TESTING
WHAT
WHY
Analyze code, both statically and dynamically, to identify potential
security issues: vulnerabilities, defensive programming patterns,
etc.
As applications grow in complexity, and as more and more
services are directly exposed to end consumers over the Internet,
and as we speed up the release processes thanks to DevOps, it is
adamant to have automated security tests along the life-cycle.
Prevent impersonation, personal and sensible information leaks
(passwords, social security numbers, credit card data), business
confidential information, secret reports, etc.
Scans look at both source code and external dependencies!

SECURITY TESTING TOOLS
ZAP Dependency Check

ZAP
Dynamic profiler – Two modes:
Passive Scan
Works as an HTTP proxy
Analyzes HTTP requests and responses (for example, during test
execution, ideally automated in a CI/CD pipeline)
Looks for known vulnerabilities like:
 SQL injection
 Cross site request forgery (CSRF)
 Cross site scripting (XSS)
 Cookie handling

ZAP
Dynamic profiler – Two modes:
Active Scan
Launch coordinated attacks on the target application
It should be executed only in applications you are authorized to
Never in production, it can break things, and lead to data loss
It may take a long, long time to complete a full scan, even in a
simple application

ZAP

Dependency Check
Scan dependencies for a given project/module,
looking for known vulnerabilities in those
dependencies (version-wise)
Uses NIST National Vulnerability Database (NVD)
Can be run from command-line, Ant, Maven, Gradle,
sbt or Jenkins

Dependency Check

SUMMARY
PROFILE YOUR CODE
Pick a static code
profiler to automate
review of coding
standards and common
best practices
MEASURE COVERAGE
Understand which
parts of your code are
not being tested by
mixing code coverage
and mutation testing
SECURITY FIRST
Put security first by
combining defensive
programming patterns
with checks from static
and dynamic profilers
MOCKS ARE GOOD
They help to make tests
repeatable and
independent from the
environment, and make
testable, code that isn’t

REFERENCES
SonarQube – https://www.sonarqube.org
ESLint – https://eslint.org
EclEmma & JaCoCo – http://www.eclemma.org
Pitest – http://pitest.org
JMockit – http://jmockit.org
FindSecBugs – https://find-sec-bugs.github.io
OWASP ZAP – https://www.owasp.org/index.php/ZAP
OWASP Dependency Check –
https://www.owasp.org/index.php/OWASP_Dependency_Check

MORE TALKS AT JAVAONE 2017
CON3282 – Code Generation with Annotation Processors
Wed 4th, 9.30, Moscone West 2018
CON3276 – Selenium Testing Patterns Reloaded
CON4258 – Continuous Code Quality with SonarQube and SonarLint
Tue 3rd, 8.30, Moscone West 2009
CON2361 – Web Application Security for Developers: Tooling and Best Practices
CON1694 – Intro to Mutation Testing in Java
Thu 5th, 12.45, Marriott Marquis Nob Hill C/D
ALWAYS CHECK THE CONFERENCE AGENDA/APP FOR LAST-MINUTE CHANGES!

JavaOne 2017 CON2902 - Java Code Inspection and Testing Power Tools

More Related Content

What's hot (20)

Similar to JavaOne 2017 CON2902 - Java Code Inspection and Testing Power Tools (20)

More from Jorge Hidalgo (20)

Recently uploaded (20)

JavaOne 2017 CON2902 - Java Code Inspection and Testing Power Tools