4Developers 2015: Sprytniejsze testowanie kodu Java ze Spock Framework - Marcin Zajączkowski

Smarter testing Java code
with Spock Framework
Including changes in Spock 1.0
Marcin Zajączkowski @SolidSoftBlog http://blog.solidsoft.info/
Warszawa, 20th April 2015

About me

2 interesting companies

Agenda
Why I like Spock?
Less know, but cool Spock features
New and noteworthy in Spock 1.0
Spock tricks

Why idea for this presentation?
JUnit/TestNG + Mockito + AssertJ work...
... but Spock brings testing to another level
Integrates seamlessly with production Java code
Since version 1.0 provides even more useful features

Why idea for this presentation?
JUnit/TestNG + Mockito + AssertJ work...
... but Spock brings testing to another level
Integrates seamlessly with production Java code
Since version 1.0 provides even more useful features
Encourage more people to using Spock
In even more effective way

Why I like Spock?
Consist and readable test code
Tests as specification by default
All Groovy magic available to help
Embedded mocking framework
Although Mockito can be used if preferred
Highly extensible
Compatible with tools supporting JUnit

Simple specification in Spock
given/when/then (or expect) are required to compile code
class SimpleCalculatorSpec extends Specification {
def "should add two numbers"() {
given:
def sut = new Calculator()
when:
def result = sut.add(1, 2)
then:
result == 3
}
}

Conditional test exection

@Requires
Runs annotated test (or the whole specification) only if
given criteria are met
Useful to depend on JVM version, operating system,
activated profile, custom system property, etc.
Opposite to @IgnoreIf

@Requires
Runs annotated test (or the whole specification) only if
given criteria are met
Useful to depend on JVM version, operating system,
activated profile, custom system property, etc.
Opposite to @IgnoreIf
1.0

@Requires - continued
Provides access to system properties and environment
variables
@Requires({ System.getProperty("os.arch") == "amd64" })
def "should use optimization on 64-bit systems"() { ... }
@Requires({ env.containsKey("ENABLE_CRM_INTEGRATION_TESTS") })
def "should do complicated things with CRM"() { ... }

Can use static methods
import static FancyFeatureRequiredIntranetConnectionSpecIT.isUrlAvailable
@Requires({ isUrlAvailable("http://some-host.intranet/") })
class FancyFeatureRequiredIntranetConnectionSpecIT extends Specification {
//could be also from trait or other class
static boolean isUrlAvailable(String url) {
//...
}
def "should do one thing in intranet"() { ... }
def "should do another thing in intranet"() { ... }
...
}

//...
}
...
}
Import is required to prevent MissingMethodException

@Memoized
//...
}
...
}
@Memoizedfor caching

@IgnoreIf and @Requires - new features
spock.util.environment.Jvm
Simple and convenient access to Java version
(java.versionand java.specification.version)
boolean isJava7() //true only if Java 7
boolean isJava8Compatible() //true if Java 8+
String getJavaVersion() //e.g. "1.8.0_05"
String getJavaSpecificationVersion() //e.g. "1.8"
@IgnoreIf({ !jvm.java8Compatible })
def "should find at runtime and use CompletableFuture for Java 8+"() {
...
}

spock.util.environment.Jvm
Simple and convenient access to Java version
(java.versionand java.specification.version)
boolean isJava7() //true only if Java 7
boolean isJava8Compatible() //true if Java 8+
String getJavaVersion() //e.g. "1.8.0_05"
String getJavaSpecificationVersion() //e.g. "1.8"
@IgnoreIf({ !jvm.java8Compatible })
def "should find at runtime and use CompletableFuture for Java 8+"() {
...
}
1.0

spock.util.environment.OperatingSystem
Simple and convenient access to OS information
(os.nameand os.versionsystem properties)
String getName() //Linux
String getVersion() //8.1
Family getFamily() //SOLARIS (enum)
boolean isLinux()
boolean isWindows()
boolean isMacOs() //also Solaris and Other
boolean iSolaris()
boolean isOther()
@Requires({ os.linux || os.macOs })
def "should use fancy console features"() { ... }

spock.util.environment.OperatingSystem
Simple and convenient access to OS information
(os.nameand os.versionsystem properties)
String getName() //Linux
String getVersion() //8.1
Family getFamily() //SOLARIS (enum)
boolean isLinux()
boolean isWindows()
boolean isMacOs() //also Solaris and Other
boolean iSolaris()
boolean isOther()
@Requires({ os.linux || os.macOs })
def "should use fancy console features"() { ... }
1.0

Cleaning up

@RestoreSystemProperties
Restores original system properties
From System.getProperties()
To a state before test

@RestoreSystemProperties - example
@Stepwise
class RestoreSystemPropertiesSpec extends Specification {
def "should deny perform action when running as root"() {
given:
System.setProperty("user.name", "root")
and:
def sut = new DangerousActionPerformer()
when:
sut.squashThemAll()
then:
thrown(IllegalStateException)
}
def "should perform action when running as 'normal' user"() {
given:
def sut = new DangerousActionPerformer()
when:
sut.squashThemAll()
then:
noExceptionThrown()
}
}

Useful in integration tests when playing with them
E.g. testing Spring profiles activation based on system
property
Two modes
For one feature (test)
For the whole specification
Just like using for every test

Useful in integration tests when playing with them
E.g. testing Spring profiles activation based on system
property
Two modes
For one feature (test)
For the whole specification
Just like using for every test
1.0

@AutoCleanup
Cleans up resource at the end of its life time

@AutoCleanup - with separate cleanup
class FancyDBSpec extends Specification {
@Shared
private DBConnection dbConnection = new H2DBConnection(...)
def cleanupSpec() {
dbConnection.release()
}
def "should do fancy things on DB"() {
...
}
def "should do fancy2 things on DB"() {
...
}
}
interface DBConnection {
...
void release();
}

@AutoCleanup - example
class FancyDBSpec extends Specification {
@AutoCleanup("release")
@Shared
private DBConnection dbConnection = new H2DBConnection(...)
def "should do fancy things on DB"() {
...
}
def "should do fancy2 things on DB"() {
...
}
}
interface DBConnection {
...
void release();
}

@AutoCleanup
Applied on field
No need to use separate cleaup/cleanupSpecmethod
Supports both instance (per feature) and
shared (per specification) variables
By default method close()is called
Can be overridden with @AutoCleanup("release")
@AutoCleanup(quiet = true)to suppress exception logging

@AutoCleanup
Applied on field
No need to use separate cleaup/cleanupSpecmethod
Supports both instance (per feature) and
shared (per specification) variables
By default method close()is called
Can be overridden with @AutoCleanup("release")
@AutoCleanup(quiet = true)to suppress exception logging
0.7

Initialization and clean up in test
setup/cleanupcan be declared per feature
useful if feature specific operations

def "complex logic should work with fixed thread pool"() {
setup: //alias for 'given:'
ExecutorService threadPool = Executors.newFixedThreadPool(1)
when:
String returnedValue = threadPool
.submit({ "val" } as Callable)
.get(1, TimeUnit.SECONDS)
then:
returnedValue == "val"
cleanup:
threadPool?.shutdown()
}

setupalias for given
cleanuplike finallyexecuted even on exception
works for every iteration (where)

Native support for JUnit before/after
annotations
By default setupSpec(), setup(), cleanup(), cleanupSpec()
In addition @BeforeClass, @Before, @After, @AfterClass
Can be mixed together (also through class hierarchy)
No longer called twice in super class
More than one method of given type can be provided
Useful when dealing with
Additional testing frameworks like in Grails
Traits with setup/clean up code
1.0

Simplifying specifications with traits
Share common logic across different specifications
No specification inheritance involved
Can provide setup/cleanup methods
Can have instance variables
Groovy 2.3+ is required
G
roovy2.3

trait DatabaseTrait {
@Shared
DBConnection dbConnection
def setupSpec() { //or @BeforeClass
//prepare DB
}
def cleanupSpec() { //or @AfterClass
//clean up DB
}
}

trait DatabaseTrait {
@Shared
DBConnection dbConnection
def setupSpec() { //or @BeforeClass
//prepare DB
}
def cleanupSpec() { //or @AfterClass
//clean up DB
}
}
class Fancy1DatabaseSpec extends Specification implements DatabaseTrait {
def "should do fancy1 thing on database"() {
//fancy1 things on database
}
}
class Fancy2DatabaseSpec extends Specification implements DatabaseTrait {
def "should do fancy2 thing on database"() {
//fancy2 things on database
}
}

Parametrized tests

Parametrized tests - basic case
def "should add two integers"() {
given:
Calculator sut = new SimpleCalculator()
when:
int result = sut.add(x, y)
then:
result == expectedResult
where:
x | y || expectedResult
1 | 2 || 3
-2 | 3 || 1
-1 | -2 || -3
}
build-in support with wherekeyword
does not stop on failure for given test case
syntatic sugar for table-like data formatting

Parametrized tests - could look better
private PESELValidator sut = new FakePESELValidator()
def "should validate PESEL correctness"() {
expect:
sut.validate(pesel) == isValid
where:
pesel || isValid
"123" || false
"abcd" || false
"97110208631" || true
}

Parametrized tests - could look better
private PESELValidator sut = new FakePESELValidator()
expect:
where:
pesel || isValid
"123" || false
"abcd" || false
"97110208631" || true
}
one combined test for all test cases
not very readable in case of failure(s)

Parametrized tests - @Unroll
@Unroll
def "should validate PESEL correctness (multiple tests)"() {
expect:
where:
pesel || isValid
"123" || false
"abcd" || false
"97110208631" || true
}

Parametrized tests - @Unroll
@Unroll
def "should validate PESEL correctness (multiple tests)"() {
expect:
where:
pesel || isValid
"123" || false
"abcd" || false
"97110208631" || true
}
@Unrollto generate separate test per test case
still confusing in case of failure

Parametrized tests - @Unroll + #pesel
@Unroll
def "should validate PESEL (#pesel) correctness (#isValid)"() {
expect:
where:
pesel || isValid
"123" || false
"abcd" || false
"97110208631" || true
}

Parametrized tests - @Unroll + #pesel
@Unroll
def "should validate PESEL (#pesel) correctness (#isValid)"() {
expect:
where:
pesel || isValid
"123" || false
"abcd" || false
"97110208631" || true
}
#peseland #isValidto put input parameter into test report
more readable, but still can be confusing for business
people reading BDD reports

Parametrized tests - @Unroll with message
@Unroll("PESEL '#pesel' should be #description")
expect:
where:
pesel || isValid
"123" || false
"abcd" || false
"97110208631" || true
description = isValid ? "valid" : "invalid"
}

Parametrized tests - @Unroll with message
expect:
where:
pesel || isValid
"123" || false
"abcd" || false
"97110208631" || true
}
distinguish test name
and test description
used in test report
additional (artificial) parameter for test report only
with autocompletion in IntelliJ IDEA

Parametrized tests - data pipes
expect:
where:
pesel << ["123", "abcd", "97110208631"]
isValid << [false, false, true]
}
table is syntatic sugar for data pipes
"<<" operator to connect data variable with data provider

Parametrized tests - more data providers
@Unroll("#pesel is valid (#dbId)")
def "should validate PESEL correctness (CSV)"() {
expect:
sut.validate(pesel)
where:
[dbId, _, _, pesel] << readValidPeopleFromCSVFile()
.readLines().collect { it.split(',') }
//ugly way to read CSV - don't do this
}
not only static elements
everything iterable in Groovy
also SQL rows or CSV files

Mocking

Simple Stubbing
class DaoSpec extends Specification {
def "should stub method call"() {
given:
Dao dao = Stub(Dao)
dao.getCount() >> 1
expect:
dao.getCount() == 1
}
}
interface Dao {
int getCount()
Item save(Item item)
}

Simple Stubbing - inline
private Dao<Item> dao = Stub(Dao) {
dao.getCount() >> 1
}
def "should stub method call"() {
expect:
dao.getCount() == 1
}
}

Simple Stubbing - consecutive calls
def "should stub consecutive calls"() {
given:
Dao<Item> dao = Stub(Dao)
dao.getCount() >> 1 >> 2
expect:
dao.getCount() == 1
and:
dao.getCount() == 2
and:
dao.getCount() == 2
}
}

Simple Stubbing - consecutive calls (list)
def "should stub consecutive calls (list)"() {
given:
dao.getCount() >>> [1, 2]
expect:
dao.getCount() == 1
and:
dao.getCount() == 2
and:
dao.getCount() == 2
}
}

Simple Stubbing - input parameters (array)
def "should stub method call to return input value"() {
given:
Item baseItem = new Item()
and:
dao.save(_) >> { it[0] }
when:
Item returnedItem = dao.save(baseItem)
then:
baseItem.is(returnedItem)
}
}
by default array of input parameters

Simple Stubbing - named input parameters
def "should stub method call to return input value"() {
given:
and:
dao.save(_) >> { Item item -> item }
when:
then:
}
}
can be declared explicit as named (and typed) parameters
all have to be declared

Simple Stubbing - throwing exception
def "should throw exception for specific input parameters"() {
given:
dao.save(_) >> { Item item ->
throw new IllegalArgumentException(item.toString())
}
when:
dao.save(new Item())
then:
thrown(IllegalArgumentException)
}
}

Simple Stubbing - throwing exception
def "should throw exception for specific input parameters"() {
given:
dao.save(_) >> { Item item ->
throw new IllegalArgumentException(item.toString())
}
when:
then:
when:
dao.save(null)
then:
}
}
smart toString()from Groovy (for null objects)

Stubbing and verifying together
def "should stub and verify"() {
given:
and:
when:
then:
1 * dao.save(_) >> { Item item -> item }
and:
}
}
has to be in the same statement
in thensection

Overriding stubbed value
class BusinessServiceSpec extends Specification {
private BoringCollaborator boringStub = Stub(BoringCollaborator) {
sendPing() >> "OK"
}
private BusinessService sut = new BusinessService(boringStub)
def "should calculate important business case 1"() {
when:
int result = sut.calculateImportantThings()
then:
result == EXPECTED_RESULT_1
}
def "should calculate important business case 2"() { ... }
many positive cases with sendPing() >> "OK"
how to test negative scenario?

Overriding stubbed value - broken
sendPing() >> "OK"
}
@Ignore("broken")
def "should cover collaborator error"() {
given:
boringStub.sendPing() >> "ERROR" //does not work!
when:
sut.calculateImportantThings()
then:
}
override in Mockito style does not work

Overriding stubbed value - in thensection
sendPing() >> "OK"
}
def "should cover collaborator error"() {
when:
sut.calculateImportantThings()
then:
boringStub.sendPing() >> "ERROR" //stubbing in "then", looks bad
and:
}
has to placed in thensection

Verification in order - issue
@Ignore("broken")
def "notification should be send after business operation (ignore order)"() {
given:
Dao dao = Mock()
Notifier notifier = Mock()
and:
def sut = new BusinessService(dao, notifier)
when:
sut.processOrder()
then:
1 * dao.saveOrder(_) //order does not matter
1 * notifier.sendNotification(_)
}
order is not verified
notification could be send before saving order

Verification in order - solution
def "notification should be send after business operation"() {
given:
Dao dao = Mock()
and:
when:
sut.processOrder()
then:
1 * dao.saveOrder(_)
then:
}
mutiple then block are evaluated separately

Verification in order - gotcha
@Ignore("broken")
def "notification should be send after business operation (with 'and')"() {
given:
Dao dao = Mock()
and:
when:
sut.processOrder()
then:
1 * dao.saveOrder(_)
and: //'and' does not verify execution order
}
anddoes not verify execution order
it is for documentation purposes only

Miscellaneous

Active condition waiting
PoolingConditions
Active waiting for condition to pass - like in Awaitility
No more sleep(3000)

Active condition waiting - example
def "should receive packet after while"() {
given:
def conditions = new PollingConditions()
def asynchronousMessageQueue = new DelayedDeliveryMessageQueueFacade()
when:
asynchronousMessageQueue.sendPing()
then:
conditions.eventually {
assert asynchronousMessageQueue.numberOfReceivedPackets == 1
}
}
With default values

given:
def conditions = new PollingConditions(timeout: 2, initialDelay: 0.3)
when:
then:
}
}
With custom configuration

given:
def conditions = new PollingConditions(timeout: 2, initialDelay: 0.3)
when:
then:
conditions.within(5) {
}
}
withing(timeoutInSeconds)can override original timeout in
specific call

given:
PollingConditions conditions = new PollingConditions()
when:
then:
asynchronousMessageQueue.numberOfReceivedPackets == 1
}
}
assertkeyword can omitted when PollingConditionsis
declared explicit (not with def)

PoolingConditions
No more sleep(3000)
Ability to specify: timeout, initialDelay, delay and factor
assertkeyword is (usually) required
Useful in multithreading code and asynchronous external
calls (like message queues)
Cannot be used for interaction verification

PoolingConditions
No more sleep(3000)
Ability to specify: timeout, initialDelay, delay and factor
assertkeyword is (usually) required
Useful in multithreading code and asynchronous external
calls (like message queues)
Cannot be used for interaction verification
0.7

Asserting previous value (manual way)
Check if/how given value was changed
def "should create new record when item is saved (manual way)"() {
given:
Dao dao = new DummyDao()
and:
int originalNumberOfRecords = dao.getCount()
when:
then:
dao.getCount() == originalNumberOfRecords + 1
}
interface Dao {
int getCount()
void save(Item item)
}

Asserting previous value (Spock way)
def "should create new record when item is saved"() {
given:
Dao dao = new DummyDao()
when:
then:
dao.getCount() == old(dao.getCount()) + 1
}
interface Dao {
int getCount()
void save(Item item)
}
Spock generates code to keep the old value
Works with fields and methods

BDD-like documentation
Highlight business context
Block description (when: "put element on stack")
@See("https://en.wikipedia.org/wiki/Spock")
@Issue("http://tinyurl.com/spock-issue260")
@Subject("TODO: przyklady")
@Title
@Narrative

Optional runtime configuration
Configures Spock behavior
Injectable into run context and extensions
By default for
Runner
Report
Ability to create custom configuration when needed
0.7, 1.0

Optional runtime configuration
~/.spock/SpockConfig.groovy
runner {
include package.DefaultSpecificationBaseClass
exclude package.IntegrationAnnotation
optimizeRunOrder = true
filterStackTrace = false
}
report {
enabled = true
issueNamePrefix = "JLTN-"
issueUrlPrefix = "https://github.com/Confitura/jelatyna/issues"
logFileSuffix = ".log"
...
}
0.7, 1.0

Optional runtime configuration - location
Reads from SpockConfig.groovytaken from:
-Dspock.configuration
Classpath
Spock home directory
-Dspock.user.home
$SPOCK_USER_HOME
~/.spock/
0.7, 1.0

Exception util
Makes assertions on nested exception causes easier
Taken after Grails
spock.util.Exceptions
Throwable getRootCause(Throwable exception)
List<Throwable> getCauseChain(Throwable exception)

Exception util
Taken after Grails
def "should throw business exception on communication error keeping original"()
when:
sut.sendPing(TEST_REQUEST_ID)
then:
def e = thrown(CommunicationException)
e.message == "Communication problem when sending request with id: 5"
Exceptions.getRootCause(e).class == ConnectException
}

Exception util
Taken after Grails
def "should throw business exception on communication error keeping original"()
when:
sut.sendPing(TEST_REQUEST_ID)
then:
def e = thrown(CommunicationException)
e.message == "Communication problem when sending request with id: 5"
Exceptions.getRootCause(e).class == ConnectException
}
1.0

Extensibility
Powerful extension mechanism
Many of features implemented as built-in extensions
Most of already presented
Official extensions available as separate modules
Spring, Guice, Tapestry, Unitils
(Sometimes) easier to write one's own extension than
have accepted pull request
JUnit rules (@Rule/@ClassRule) can be also used

Summary (aka Why I like Spock?)
Consist and readable test code
Tests as specification by default
All Groovy magic available to help
Embedded mocking framework
Although Mockito can be used if preferred
Highly extensible
Compatible with tools supporting JUnit
Marcin Zajączkowski @SolidSoftBlog Version: 1.11p-4d

Questions?
Marcin Zajączkowski
http://blog.solidsoft.info/
@SolidSoftBlog
m.zajaczkowski@gmail.com

Thank you
(and remember about the feedback!)
Marcin Zajączkowski
http://blog.solidsoft.info/
@SolidSoftBlog
m.zajaczkowski@gmail.com

4Developers 2015: Sprytniejsze testowanie kodu Java ze Spock Framework - Marcin Zajączkowski

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 4Developers 2015: Sprytniejsze testowanie kodu Java ze Spock Framework - Marcin Zajączkowski

Similar to 4Developers 2015: Sprytniejsze testowanie kodu Java ze Spock Framework - Marcin Zajączkowski (20)

Recently uploaded

Recently uploaded (20)

4Developers 2015: Sprytniejsze testowanie kodu Java ze Spock Framework - Marcin Zajączkowski