The University of Sydney Page 1
SOFT3202
Presented by Josh Burridge
Lecture content in this unit has been
developed by:
Professor Bernhard Scholz
Dr Basem Suleiman
Josh Burridge
Software Construction & Design 2
The University of Sydney Page 2
What are we doing today?
– Mockito
– Unit test design
– Mocking concepts
– Task 1
The University of Sydney Page 3
SOFT3202
Unit Test Design – without Mocking
The University of Sydney Page 4
Unit Test Design – Without Mocking
What do you test?
– Constructors?
– Accessors/Mutators? (Getters/Setters?)
– Private methods?
– Package-Private methods?
– Types?
– Existence?
– Parents/Children?
The University of Sydney Page 5
Unit Test Design – Without Mocking
How do you test?
– Testing ahead of implementation
– Stubbing
The University of Sydney Page 6
Unit Test Design – Without Mocking
boolean checkCollision(double boundsX, double boundsY,
double circleX, double circleY, double circleRadius)
– The method checks for a collision between a
circle and the bounds, and returns true if such a
collision exists. Otherwise returns false.
– Any negative numbers result in an
IllegalArgumentException (bounds start at 0,0).
The University of Sydney Page 7
Unit Test Design – Without Mocking
boolean checkCollision(double boundsX, double boundsY,
double circleX, double circleY, double circleRadius)
– What do we need to test for?
– What test classes/methods will these tests be
in?
– Test class name? Test method name?
– How should the test itself be designed?
The University of Sydney Page 8
Unit Test Design – Without Mocking
Be careful with Task 1 and the Testing Assignment!
– Testing your ability to test, not your test design
– Forces you to breach some best practices to
test more than would normally be a good idea
(a necessary compromise to avoid
implementation code complexity
The University of Sydney Page 9
SOFT3202
Mockito
The University of Sydney Page 10
Mockito
– Library to create… what?
– Works with JUnit, TestNG, any other testing
library
– Which means it can also be integrated with
Hamcrest
The University of Sydney Page 11
Mockito
Mockito Features Description
mock(), @Mock or
Mokito.mock()
Different ways to create a mock
Answer or
MockSettings
Interfaces to specify how a mock should behave
(optional and can be dangerous)
when() Specify the mock to return a value when a method is
called
Spy() or @Spy Creates a spy for a given object
@InjectMocks automatically inject mocks/spies annotated with @Mock()
or @Spy()
verify() Check methods were called with given arguments
The University of Sydney Page 12
Mockito
– Use Mockito.when() and thenReturn() to specify
a behavior when a method is called
– Example of methods supported in Mockito
Method Purpose
thenReturn(valueToBeReturned) Return a given value
thenThrow(Throwable tobeThrown) Throws given exception
Then(Answer answer) User created code to answer
The University of Sydney Page 13
Mockito
– Use Mockito.when() and thenReturn() to specify
a behavior when a method is called
– Example of methods supported in Mockito
Method Purpose
thenReturn(valueToBeReturned) Return a given value
thenThrow(Throwable tobeThrown) Throws given exception
Then(Answer answer) User created code to answer
The University of Sydney Page 14
Mockito
– Mockito.verify (T mockTobeVerified, verificationMode mode)
– Verifies certain behavior happened at least once (default) –
e.g., a method is called once
– Different verification modes are available
Verification Mode Description
Times(int wantedNoCalls) Called exactly n times, default =
1
atMost(in maxNoOfCalls) Called at most n times
atLeast(int minNoOfCalls) Called at least n times
never() Never called
Timeout (int milliseconds) Interacted in a specified time
range
The University of Sydney Page 15
SOFT3202
Unit Test Design – With Mocking
The University of Sydney Page 16
Unit Test Design – With Mocking
– The Given-When-Then structure
– Repeated code in tests
– What to mock and why?
– Don’t mock what you don’t own
– Handling Exceptions
– What to verify? What to assert?
– Asking & Telling
– Private methods don’t exist
The University of Sydney Page 17
Unit Test Design – With Mocking
– https://davesquared.net/2011/04/dont-
mock-types-you-dont-own.html
– https://web.archive.org/web/201610312223
38/https:/monkeyisland.pl/2008/04/26/askin
g-and-telling/
– https://web.archive.org/web/201701131208
58/https:/monkeyisland.pl/2009/12/07/give
n-when-then-forever/
– https://github.com/mockito/mockito/wiki/FAQ
The University of Sydney Page 18
SOFT3202
Task 1
The University of Sydney Page 19
Task 1
– Testing the ShoppingBasket API
– API (using Javadocs) has had further details
spelled out
– You will never be given the ShoppingBasket
code – only the documentation telling you what
it should be doing
The University of Sydney Page 20
Task 1
Your task:
– Write a test suite in a single test class
‘ShoppingBasketTest.java’
– In the package au.edu.Sydney.soft3202.task1
– Make this available at github.sydney.edu.au in
a private repository named SCD2_2022
– In the directory
/task1/ShoppingBasketTest.java
– Add collaborators to this repository so markers
can see your work
The University of Sydney Page 21
Task 1
– Your test suite will be run against 11 versions of
ShoppingBasket.java:
– 1 working version
– 8 different bugs you will not be told about
– 2 ‘alternative’ working versions that are
different to the original, but are still valid
implementations of the API as written
The University of Sydney Page 22
Task 1
Marking
– 5/5
– Pass the working version and both
alternative versions as ok
– Catch at least 7 of 8 bugs
– 2.5/5
– Pass the working version and at least 1
alternative version as ok
– Catch at least 4 of 8 bugs
The University of Sydney Page 23
Task 1
– Marking is performed by an autograder running
‘some time’ after midnight each day
– No extra marking runs will be used – this is
intentional, you have limited opportunities to see
the marking running
– Bugs and alternative versions will be released in
stages:
– Working version and 3 bugs on Monday
– 1 alternative version and 3 bugs on
Wednesday
– 1 alternative version and 2 bugs on Friday
The University of Sydney Page 24
Task 1
– This is practice for the Testing Assignment, which
works in a similar way, only there will be bugs
you don’t get to see until after the due date
(and the API will be more complex)
– Be ‘finished’ before bugs are released, to see
what would have happened if you weren’t
given an opportunity to correct missing test
cases or rejected working versions

欢迎咨询51作业君