JUnit and JMock

Software Engineering Class providing an overview of the main testing features of JUnit 4.x and scaffolding capabilities with JMock.

Transcript

1. UNIT TESTING WITH JUNIT Software Engineering Class Valerio Maggio, Ph.D. valerio.maggio@unina.it Prof. Adriano Peron Dec. 12, 2013
2. EXERCISE 1 Calculator
3. • Requirements:! • Input numbers cannot have more than 5 digits;! • The calculator can remember a given (unique) number;! • Only non-negative numbers are allowed.! • In case of negative numbers, an exception is thrown! Calculator + add (double augend, double addend): double + subtract (double minuend, double subtrahend): double + multiply (double multiplicand, double multiplier): double + divide (double dividend, double divisor): double + addToMemory(double number): void + recallNumber(): double - memory: double + MAX_DIGITS_LEN: int = 5 <<final>> <<static>>
4. •(Testing) TODO List: •Identify a Requirement to be covered Calculator + add (double augend, double addend): double + subtract (double minuend, double subtrahend): double + multiply (double multiplicand, double multiplier): double + divide (double dividend, double divisor): double + addToMemory(double number): void + recallNumber(): double - memory: double + MAX_DIGITS_LEN: int = 5 <<final>> <<static>>
5. •(Testing) TODO List: •Identify a Requirement to be covered •Identify Positive cases •i.e., Test will pass Calculator + add (double augend, double addend): double + subtract (double minuend, double subtrahend): double + multiply (double multiplicand, double multiplier): double + divide (double dividend, double divisor): double + addToMemory(double number): void + recallNumber(): double - memory: double + MAX_DIGITS_LEN: int = 5 <<final>> <<static>>
6. •(Testing) TODO List: •Identify a Requirement to be covered •Identify Positive cases •i.e., Test will pass •Identify Negative cases •i.e., Test will fail Calculator + add (double augend, double addend): double + subtract (double minuend, double subtrahend): double + multiply (double multiplicand, double multiplier): double + divide (double dividend, double divisor): double + addToMemory(double number): void + recallNumber(): double - memory: double + MAX_DIGITS_LEN: int = 5 <<final>> <<static>>
7. •(Testing) TODO List: •Identify a Requirement to be covered •Identify Positive cases •i.e., Test will pass •Identify Negative cases •i.e., Test will fail •Properly select the set of input data that will feed your test suite •You have many options for that… WECT Calculator + add (double augend, double addend): double + subtract (double minuend, double subtrahend): double + multiply (double multiplicand, double multiplier): double + divide (double dividend, double divisor): double + addToMemory(double number): void + recallNumber(): double - memory: double + MAX_DIGITS_LEN: int = 5 <<final>> <<static>>
8. •(Testing) TODO List: •Identify a Requirement to be covered •Identify Positive cases •i.e., Test will pass •Identify Negative cases •i.e., Test will fail •Properly select the set of input data that will feed your test suite •You have many options for that… WECT • You’re done! Calculator + add (double augend, double addend): double + subtract (double minuend, double subtrahend): double + multiply (double multiplicand, double multiplier): double + divide (double dividend, double divisor): double + addToMemory(double number): void + recallNumber(): double - memory: double + MAX_DIGITS_LEN: int = 5 <<final>> <<static>>
9. •(Testing) TODO List: •Identify a Requirement to be covered •Identify Positive cases •i.e., Test will pass •Identify Negative cases •i.e., Test will fail •Properly select the set of input data that will feed your test suite •You have many options for that… WECT • You’re done! Calculator + add (double augend, double addend): double + subtract (double minuend, double subtrahend): double + multiply (double multiplicand, double multiplier): double + divide (double dividend, double divisor): double + addToMemory(double number): void + recallNumber(): double - memory: double + MAX_DIGITS_LEN: int = 5 <<final>> <<static>> RQ3: Only non-negative numbers are allowed.! 
 RQ3.1: In case of negative numbers, an exception is thrown!
10. Any Idea?
11. Any Idea? Can we do better?
13. Do you see any “Bad smell”?
14. Test every input
15. Test every input Are we done yet?
16. Test special input
17. Test special input Division by Zero
18. Test special input Division by Zero “Special” Case on Negative Values
19. EXERCISE 1I Stack
20. STACK: LIFO QUEUE Stack <<constructor>> + Stack(capacity: int) + pop(): Process + push(Process p): void Process + getName():String + setName(String n): void +getPid(): Integer + setPid(Integer pid): void +getPriority():Integer +setPriority(Integer p): void - name: String - pid: Integer - priority: Integer (default=-1) * 1 _list
21. BRIEF RECAP OF: “PROGRAMMING CLASS” FIFO QUEUE
22. BRIEF RECAP OF: “PROGRAMMING CLASS” FIFO QUEUE enqueue()
23. BRIEF RECAP OF: “PROGRAMMING CLASS” FIFO QUEUE enqueue()
24. BRIEF RECAP OF: “PROGRAMMING CLASS” FIFO QUEUE enqueue() dequeue()
25. BRIEF RECAP OF: “PROGRAMMING CLASS” FIFO QUEUE enqueue() dequeue()
26. BRIEF RECAP OF: “PROGRAMMING CLASS” enqueue() dequeue() LIFO QUEUE
27. BRIEF RECAP OF: “PROGRAMMING CLASS” enqueue() dequeue() LIFO QUEUE
28. BRIEF RECAP OF: “PROGRAMMING CLASS” enqueue() dequeue() LIFO QUEUE
29. BRIEF RECAP OF: “PROGRAMMING CLASS” enqueue() dequeue() LIFO QUEUE
30. STACK LIFO QUEUE TEST • push(Process):void • pop():Process
31. STACK LIFO QUEUE TEST • push(Process):void • Start with an empty Stack • pop():Process
32. STACK LIFO QUEUE TEST • push(Process):void • Start with an empty Stack • Add a new Process • pop():Process
33. STACK LIFO QUEUE TEST • push(Process):void • Start with an empty Stack • Add a new Process • Check that Process is the head • pop():Process
34. STACK LIFO QUEUE TEST • push(Process):void • Start with an empty Stack • Add a new Process • Check that Process is the head • we assume that we had on top • pop():Process
35. STACK LIFO QUEUE TEST • push(Process):void • Start with an empty Stack • Add a new Process • Check that Process is the head • we assume that we had on top • pop():Process • Start with an Empty Stack
36. STACK LIFO QUEUE TEST • push(Process):void • Start with an empty Stack • Add a new Process • Check that Process is the head • we assume that we had on top • pop():Process • Start with an Empty Stack • Push an Element
37. STACK LIFO QUEUE TEST • push(Process):void • Start with an empty Stack • Add a new Process • Check that Process is the head • we assume that we had on top • pop():Process • Start with an Empty Stack • Push an Element • Pop the Element
38. STACK LIFO QUEUE TEST • push(Process):void • Start with an empty Stack • Add a new Process • Check that Process is the head • we assume that we had on top • pop():Process • Start with an Empty Stack • Push an Element • Pop the Element • Verify that removed element is the same
39. STACK LIFO QUEUE TEST • push(Process):void • Start with an empty Stack • Add a new Process • Check that Process is the head • we assume that we had on top • pop():Process • Start with an Empty Stack • Push an Element • Pop the Element • Verify that removed element is the same • Test pop on Empty Stack
43. Can we do better? … We do!
45. Assertion with Matchers
46. Assertion with Matchers “is”(Hamcrest) 
 Matcher
47. Assertion with Matchers “is”(Hamcrest) 
 Matcher https://code.google.com/p/hamcrest/
48. TESTING WITH MATCHERS (EXAMPLE) Using matchers on collections!
49. TESTING Stack.pop
50. TESTING Stack.pop Please look at JUnit Assumptions
51. JUNIT ASSUMPTIONS If you don’t know, you may assume!
52. Extended EXAMPLE + enqueue(Process p):void + dequeue():Process <<abstract>> Queue * 1 _list Process FIFOQueue LIFOQueue PriorityQueue + addProcess(Process p, Queue q):void + schedule(Queue q):Process Scheduler 1 * _queues Q: How would you test Scheduler?
53. TEST SCAFFOLDING
54. TESTING IN ISOLATION Testing in Isolation benefits!
55. TESTING IN ISOLATION Test code not yet written Testing in Isolation benefits!
56. TESTING IN ISOLATION Test only a single method (behaviour) without side effects from other objects Test code not yet written Testing in Isolation benefits!
57. INTEGRATION TESTING
58. INTEGRATION TESTING
59. SCHEDULER EXAMPLE + enqueue(Process p):void + dequeue():Process <<abstract>> Queue * 1 _list Process FIFOQueue LIFOQueue PriorityQueue + addProcess(Process p, Queue q):void + schedule(Queue q):Process Scheduler 1 * _queues
60. s:Scheduler client addProcess(P, Q) q:Queue enqueue(P) SCHEDULER@addProcess
61. SOLUTION WITH STUBS @Marco Zeuli
62. SOLUTION WITH STUBS @Marco Zeuli
63. KEY IDEAS • Wrap all the details of Code! • (sort of) Simulation
 • Mocks do not provide our own implementation of the components we'd like to swap in
 • Main Difference: • Mocks test behavior and interactions between components
 • Stubs replace heavyweight process that are not relevant to a particular test with simple implementations
64. MOCK OBJECTS • Powerful way to implement Behavior Verification ! • while avoiding Test Code Duplication between similar tests.
 • It works by delegating the job of verifying the indirect outputs of the SUT! ! • Important Note: Design for Mockability! • Dependency Injection Pattern
65. NAMING CONFUSION • Unfortunately, while two components are quite distinct, they're used interchangeably.! • Example: spring-mock package
 • If we were to be stricter in terms of naming, stub objects defined previously are test doubles
 • Test Doubles, Stubs, Mocks, Fake Objects… how could we work it out ?
66. TEST DOUBLE PATTERN 
 • Q: How can we verify logic independently when code it depends on is unusable?! • Q1: How we can avoid slow tests ?! • A: We replace a component on which the SUT depends with a “test- specific equivalent.”
67. TEST STUB PATTERN • Q: How can we verify logic independently when it depends on indirect inputs from other software components ?! • A: We replace a real objects with a test-specific object that feeds the desired inputs into the SUT
68. MOCKS OBJECTS • Q: How can we implement Behavior Verification for indirect outputs of the SUT ?! • A: We replace an object on which the SUT depends on with a test- specific object that verifies it is being used correctly by the SUT.
69. MOCK LIBRARIES • Two main design philosophy:! • DSL Libraries! • Record/Replay Models Libraries
 Record Replay Frameworks: First train mocks and then verify expectations DSL Frameworks: •Domain Specific Languages! •Specifications embedded in “Java” Code
70. MOCK LIBRARIES • Two main design philosophy:! • DSL Libraries! • Record/Replay Models Libraries
 Record Replay Frameworks: First train mocks and then verify expectations DSL Frameworks: •Domain Specific Languages! •Specifications embedded in “Java” Code
71. SOLUTION WITH JMOCK
72. JMOCK MAIN FEATURES
73. JMOCK FEATURES (INTRO) • JMock previous versions required subclassing! • Not so smart in testing! ! • Now directly integrated with Junit4! ! • JMock tests requires more typing! ! • JMock API is extensible
74. JMOCK FEATURES • JMock syntax relies heavily on chained method calls! • Sometimes difficult to decipher and to debug
 • Common Patterns:
 invocation-count(mockobject).method(arguments);
 inSequence(sequence-name);
 when(state-machine.is(state-name));
 will(action);
 then(state-machine.is(new-state name));
75. 1. TEST FIXTURE • Mockery represents the context! • JUnitRuleMockery replaces the @RunWith(JMock.class) annotation! • JUnit4Mockery reports expectation failures as JUnit4 test failures
76. 2. CREATE MOCK OBJECTS • References (fields and Vars) have to be final! • Accessible from Anonymous Expectations
77. 3. TESTS WITH EXPECTATIONS • A test sets up it expectations in one or more expectation blocks! • An expectation block can contain any number of expectations! • Expectation blocks can be interleaved with calls to the code under test.
78. 3. TESTS WITH EXPECTATIONS • Expectations have the following structure: invocation-count(mockobject).method(arguments); inSequence(sequence-name); when(state-machine.is(state-name)); will(action); then(state-machine.is(new-state name));
79. WHAT ARE THOSE DOUBLE BRACES? • Anonymous subclass of Expectations! • Baroque structure to provide a scope for setting expectations! • Collection of expectation components! • Is an example of Builder Pattern! • Improves code completion
80. COOKBOOK: EXPECT A SEQUENCE OF INVOCATIONS Expect that a sequence of method calls has been executed in the right order @Marco Zeuli
81. @Marco Zeuli EXPECT A SEQUENCE OF INVOCATIONS
82. CONTACTS MAIL: valerio.maggio@unina.it http://wpage.unina.it/valerio.maggio
83. REFERENCES (1) Growing Object-Oriented Software, Guided By Tests! Freeman and Pryce, Addison Wesley 2010 JMock Project WebSite! (http://jmock.org)
84. REFERENCES (II) xUnit Test Patterns: Refactoring Test Code! Meszaros G., Pearson Education 2007