Por qué usar Spock en lugar de JUnit / Mockito para tus tests Java - Codemotion 2016

MADRID · NOV 18-19 · 2016
Why Using
by @andres_viedma
instead of
in your Java Tests

Andrés ViedmaAndrés Viedma
@andres_viedma@andres_viedma

A testing framework
Tests are written in
100% compatible with Java code
Runs on
http://spockframework.org/

A basic JUnit test
@Test
public void thatAddAPositiveNumberToZeroReturnsTheSamePositiveNumber()
throws Exception {
int positiveNumber = 23;
int zero = 0;
int result = zero + positiveNumber;
assertEquals(positiveNumber, result);
}

A basic Spock test
def "Add a positive number to zero returns the same positive number"() {
given:
def positiveNumber = 23
def zero = 0
when:
def result = zero + positiveNumber
then:
result == positiveNumber
}

A basic Spock test
DSL
given:
def zero = 0
when:
then:
}

String literals
(...)
}
@Test
throws Exception {
(...)
}

String literals
(...)
}
@Test
throws Exception {
(...)
}
def "En un lugar de la Mancha, de cuyo nombre no quiero acordarme,
no ha mucho tiempo que vivía un hidalgo de los de lanza en astillero,
adarga antigua, rocín flaco y galgo corredor. "() {
(...)
}

Spock Blocks
given:
def zero = 0
when:
then:
int zero = 0;
Programming vs. Specification

Spock Blocks
given:
def zero = 0
when:
then:
// Given
int zero = 0;
// When
// Then
Compilation check
Programming vs. Specification

Documented Spock Blocks
given: "A positive number"
and: "Well... a SPECTACULAR zero"
def zero = 0
when: "The number is added to zero"
then: "The result is the same number"
int zero = 0;
Documents purpose
Helps thinking

expect block
given: "A positive number"
expect: "That added to zero results the same number"
zero + positiveNumber == positiveNumber
Replaces when-then for simple
functional tests

Expectations (then / expect)
given:
def zero = 0
when:
then:
int zero = 0;

Multiple expectations
then:
!collection.isEmpty()
then:
and:

Multiple expectations
then:
then:
def expectedResult = positiveNumber
result == expectedResult
Only conditions and variable
assignments allowed
then:
and:

def "Crash if zero"() {
when:
object.crashIfZero(0)
then:
thrown(ZeroException)
}
@Test(expected = OperationException.class)
public void crashIfZero()
throws Exception {
object.crashIfZero(0);
}
Exception conditions

def "Crash if zero"() {
when:
then:
thrown(ZeroException)
}
@Test(expected = OperationException.class)
public void crashIfZero()
throws Exception {
}
def "Dont crash if not zero"() {
when:
then:
notThrown(ZeroException)
}
@Test // No exception should be thrown
public void dontCrashIfNotZero()
throws Exception {
}
Exception conditions

class KakaSpec extends Specification {
static final SUBSCRIPTION_ID = 27
private AuxiliarObject auxiliar
void setup() {
(...)
}
def "xxx"() {
(...)
}
}
public class XxxxxxxxxxTest {
private static final long SUBSCRIPTION_ID = 27;
private AuxiliarObject auxiliar;
@Before
public void setUp() throws Exception {
(...)
}
@Test
public void thatXxx() throws Exception {
(...)
}
}
The test class

Groovy syntax sugar
when:
def result = object.getRecords()
then:
result?.list == [1, 47, 23]
Optional types
Collection literals
No ; needed
== operator for equals
Safe navigation ?. operator

Mocks Creation
@Mock
private CustomerDataRegistry customerRegistry;
(...)
private PaymentsCoordinator paymentCoordinator;
@Before
public void setup() {
MockitoAnnotations.initMocks(this);
paymentCoordinator = new PaymentsCoordinator(
customerRegistry, (...));
}
CustomerDataRegistry customerRegistry = Mock()
(...)
@Subject PaymentsCoordinator paymentCoordinator =
new PaymentsCoordinator(customerRegistry, (...))

Responses declaration
@Test
public void testSuccessfulPaymentWithNewCreditCard() throws Exception {
when(customerRegistry.getCustomerData(SUBSCRIPTION_ID)).thenReturn(CUSTOMER_DATA);
(...)
PaymentResult result = paymentCoordinator.doPayment(paymentData);
(...)
}
def "Succesful payment with new credit card"() {
given: "A registered customer"
customerRegistry.getCustomerData(SUBSCRIPTION_ID) >> CUSTOMER_DATA
(...)
when: "A payment is requested"
def result = paymentCoordinator.doPayment(paymentData)
(...)
}

Interaction expectations
@Test
(...)
when(paymentInteractor.performPaymentInProvider(inputFields))
.thenReturn(PAYMENT_SUCCESSFUL_OUTPUT);
PaymentResult result = paymentCoordinator.doPayment(paymentData);
verify(paymentInteractor).performPaymentInProvider(inputFields)).
(...)
}
(...)
when: "A payment is requested"
def result = paymentCoordinator.doPayment(paymentData)
then: "It is sent to the payment provider with successful result"
1 * paymentInteractor.performPaymentInProvider(inputFields) >>
PAYMENT_SUCCESSFUL_OUTPUT
(...)
}

Mocks and Stubs
then:
0 * _
Semantic
Lenient: default
values
Only return values
Stubs: empty objects
Stubs: no interaction
expectations
Mocks: nulls

Call Matching
Arguments matching
mock.method("hello")
mock.method(!"hello")
mock.method()
mock.method(_)
mock.method(*_)
mock.method(_ as String)
mock.method({ l -> l.size() > 3 })
Method matching
customerRegistry._
_
customerRegistry./searchBy.*/(…)

Interactions expectations matching
Parametes matching
Order
1 * subscriber.receive("hello")
0 * subscriber.receive("hello")
(1..3) * subscriber.receive("hello")
(1.._) * subscriber.receive("hello")
(_..3) * subscriber.receive("hello")
_ * subscriber.receive("hello")
then:
1 * mock1.method1(...)
and:
1 * mock2.method2(...)
then:
1 * mock3.calledAfter1And2()
Cardinality * matching constraints

Forget the matchers
@Test
(...)
ArgumentMatcher<Payment> paymentMatcher = new ArgumentMatcher<Payment>() {
public boolean matches(Object payment) {
return ((Payment) payment).getPaymentType() != null;
}
};
verify(paymentInteractor, never()).performPaymentInProvider(
paymentMatcher, anyObject(), eq(VALIDATE));
(...)
}
(...)
then:
0 * paymentInteractor.performPaymentInProvider(
{ payment -> payment.storedCard != null }, _, VALIDATE)
(...)
}

Property-based testing (JUnit parameterized tests)
@RunWith(Parameterized.class)
public class PaymentProcessingOfANewCompletedResponseAuthorizationHandlerTest {
public static Object[][] data() {
return new Object[][] {
{ TransactionStatus.INITIALIZED, TransactionStatus.AUTHORIZED },
{ TransactionStatus.INITIALIZED, TransactionStatus.REFUSED },
{ TransactionStatus.ACCEPTED, TransactionStatus.AUTHORIZED },
{ TransactionStatus.ACCEPTED, TransactionStatus.REFUSED }
};
}
@Parameter public TransactionStatus currentStatus;
@Parameter(value=1) public TransactionStatus responseStatus;
@Test
public void test() throws Exception {
(...)
}
}

Property-based testing (Spock where)
@Unroll
def "Processing of a new completed response from status #currentStatus to #responseStatus"(
currentStatus, responseStatus) {
(...)
when:
def resultTransaction = authorizationHandler.processResponse(statusInfo, FROM_RETRY)
then:
(...)
where:
currentStatus | responseStatus
TransactionStatus.INITIALIZED | TransactionStatus.AUTHORIZED
TransactionStatus.INITIALIZED | TransactionStatus.REFUSED
TransactionStatus.ACCEPTED | TransactionStatus.AUTHORIZED
TransactionStatus.ACCEPTED | TransactionStatus.REFUSED
}

Config tests (multiline and String interpolation)
def "getRejectionReasonForError with invalid reason mapped"() {
given:
def yaml = """
paymentForm:
rejectionReasonMapping:
${ERROR_CODE}: '${REJECTION_REASON_INVALID}'
"""
def config = formConfig(yaml)
when:
def returnedReason = config.getRejectionReasonForError(ERROR_CODE)
then: "Returns general error"
returnedReason == PaymentRejectionReason.GENERAL_ERROR
}

Builders?
def payment = new PaymentTransaction(
id: TRANSACTION_ID,
subscriptionId: SUBSCRIPTION_ID,
amount: AMOUNT,
lastChangeTimestamp: OLD_TIMESTAMP)
PaymentTransaction payment = new PaymentTransactionBuilder()
.id(TRANSACTION_ID)
.subscriptionId(SUBSCRIPTION_ID)
.amount(AMOUNT)
.lastChangeTimestamp(OLD_TIMESTAMP)
.build();
Default constructor with
named parameters

def "Process an authorized payment "() {
given: "An already authorized payment"
def authorizedPayment = paymentTransactionWith(status: TransactionStatus.AUTHORIZED)
(...)
}
private PaymentTransaction paymentTransactionWith(Map overrides) {
def attrs = [
id: TRANSACTION_ID,
subscriptionId: SUBSCRIPTION_ID,
amount: AMOUNT,
status: TransactionStatus.INITIALIZED,
lastChangeTimestamp: OLD_TIMESTAMP
] + overrides
return new PaymentTransaction(attrs)
}
Objects with default properties

Private methods for readability?
PaymentTransaction transaction = givenAnAuthorizedTransaction();
paymentProcessor.processPayment(transaction, RESPONSE_DATA);
verifyTheTransactionIsTransitionedTo(ADDING_BALANCE);
verifyTheTopupIsProcessedCorrectly();

Private methods for readability?
given: "An already authorized transaction"
def transaction = transactionWith(status: AUTHORIZED)
transactionRegistry.getTransactionInfo(TRANSACTION_ID) >> transaction
when: "The payment is processed"
paymentProcessor.processPayment(transaction, RESPONSE_DATA)
then: "The transaction is transitioned to adding balance status"
1 * transactionRegistry.changeTransactionStatus(
TRANSACTION_ID, TransactionStatus.ADDING_BALANCE) >>
transactionWith(status: ADDING_BALANCE)
then: "The topup is processed"
1 * topupInteractor.topup(transaction, RESPONSE_DATA) >>
new PaymentStatusInfo(TRANSACTION_ID, TransactionStatus.BALANCE_ADDED)
PaymentTransaction transaction = givenAnAuthorizedTransaction();
paymentProcessor.processPayment(transaction, RESPONSE_DATA);
verifyTheTransactionIsTransitionedTo(ADDING_BALANCE);
verifyTheTopupIsProcessedCorrectly();

static final MERCADOPAGO_RESULT = [
status: 'approved',
status_detail: 'ok',
description: 'Tuenti (test)',
id: 999999,
authorization_code: 858,
collector_id: 5678,
statement_descriptor: 'WWW.MERCADOPAGO.COM',
card: [
last_four_digits: 1234,
expiration_year: 2016,
expiration_month: 12
],
payer: [
first_name: NAME,
last_name: LAST_NAME,
email: EMAIL,
]
]
Tests involving 3rd party APIs – Thank God for Collection
literals

●
Increase abstraction level
Not “programming tests” ® specify test cases
Easy + powerful
Expressivity ® test is also documentation
● Easy to run in continuous integration systems / IDEs
● Better error detection info
Advantages?

● Code Refactors not so safe
● Mocks can only be created in the Spec class
Integration tests with dependency injection overrides ... more
difficult, but possible!
Disadvantages?

● Code Refactors not so safe
● Mocks can only be created in the Spec class
Integration tests with dependency injection overrides ... more
difficult, but possible!
Disadvantages?
class BaseIntegrationSpecification extends TIntegrationSpecification {
@InjectOverride MercadopagoClient mercadopago = Mock()
@Inject PaymentNotificationsService paymentNotificationsServiceMock
(...)
@TIntegrationTestsModule
static class MockedBoundariesModule extends SpockMocksModule {
(...)
}
}

Andrés ViedmaAndrés Viedma
@andres_viedma@andres_viedma
Questions?

Por qué usar Spock en lugar de JUnit / Mockito para tus tests Java - Codemotion 2016

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Por qué usar Spock en lugar de JUnit / Mockito para tus tests Java - Codemotion 2016

Similar a Por qué usar Spock en lugar de JUnit / Mockito para tus tests Java - Codemotion 2016 (20)

Último

Último (20)

Por qué usar Spock en lugar de JUnit / Mockito para tus tests Java - Codemotion 2016

Notas del editor