SOFT2201/COMP9201 Week 11 Tutorial
Software Testing
Programmatic Code Testing
Copyright By PowCoder代写 加微信 powcoder
The level of testing we are interested in today takes place at about the lowest, simplest scale – testing
a single ‘unit’ of code. This is usually done through frameworks that will take in some inputs, run the
code it is testing, and then check what the code outputs to make sure it is correct.
In the general sense, every test of this nature (and most other tests) follow the same process:
• Set up the code to be tested (we call the result of this setup the ‘test fixture’)
• Give the code inputs (these inputs are known as ’test cases’)
• Check the output the code gives for those inputs (these checks are called ’assertions’)
We call this the ‘given-when-then’ test structure.
Question 1: Case Selection
The lecture gave you some strategies for selecting these test cases. As a class, apply these strategies
to build a list for the following methods:
• A method that accepts an integer that must be >=0 (if it is negative it throws an exception). If
it is given a number between 0 and 100 inclusive it returns the String “That could be a grade.”
Otherwise it returns “That is definitely not a grade.”
• A method that accepts a String. If it is given a String that contains the word “test” it outputs
“Yes, we are testing”. Otherwise it returns “Why aren’t you testing?”
SOFT2201/COMP9201 Software Testing
Question 2: API reading
Programmatic tests are a double-edged sword. On the one hand, they provide a benefit because they
can be run cheaply and easily and quickly identify potential bugs. On the other hand, it is far too easy
to assume ’the tests pass, therefore the code is bug-free’ – which is not correct. We need to handle
both verification AND validation. A key tool for making sure that verification lines up with what
validation has determined is an API reference.
As a class, review the Java 17 documentation for String, and in particular String.repeat (int count).
Assume you know nothing about repeating a String, or how you would expect this method to work.
What does this method do, based on its Javadoc description? What do you know about the precondi-
tions that govern the count parameter? Are there any preconditions aside from the parameter? What
are the post-conditions of this method?
As a short aside, consider how useful this javadoc is. Consider how useful it would be to see similar
javadoc in your own code.
Question 3: Design a Test Suite: Single Class
Without touching an IDE or writing a single line of code, you should now design a test suite for the
Oven API. The Oven class itself along with the API could be found in week 11 module on Canvas.
Make sure you can point at which parts of your test design are the ‘given’, ‘when’, and ‘then’ parts
(subheading comments work well).
Compare your tests with the ones designed by other people in your tutorial – which test cases did you
select? Did anyone think of an edge case others missed? Can you read and understand everyone’s
tests (remember tests are often used as documentation for functionality)
Question 4: Implement a Test Suite: Single Class
You should now implement and run your tests on the Oven class. You can check if your tests are
working by introducing bugs into the Oven class and seeing what your test suite is able to pick up.
(Because the Oven class refers to the Food class you will either need to skip to including the full
JAR to run these, or just create the interface with a stubbed concrete class yourself). You should try
running tests with both IntelliJ and gradle test to see the difference between them. Please note that,
tests in your weekly exercise will be run with gradle test.
Software Design and Construction 1 Page 2 of 3
https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/String.html#repeat(int)
SOFT2201/COMP9201 Software Testing
Question 5: Code Coverage
Your work requires you to ensure a particular level of code coverage. Code coverage is a metric for
test completeness, and says ’when running the tests ##% of the lines of source code were executed’.
Run your Oven test suite with coverage, and see how much of the code you have been testing.
To run coverage, you may either use IntelliJ’s built in “run with coverage” option, or you may use the
jacoco plugin for gradle. To leverage this plugin, in your build.gradle file add
id ’jacoco’
to the plugins block, then add
toolVersion = “0.8.8”
reportsDir = file(“$buildDir/customJacocoReportDir”)
jacocoTestReport {
xml.enabled false
csv.enabled false
html.destination file(“${buildDir}/jacocoHtml”)
outside any other blocks. You then run code coverage by running your tests (which will be run
any time you call test or build) then running jacocoTestReport. So for example, gradle build
jacocoTestReport. Then look for the jacocoHtml/index.html file to view the results.
Where you have missed code, consider what bugs you might have let slip through. Improve your test
suite until you have 100% coverage.
Additional Note: Unit Tests?
While the answer to this question is out of scope for this unit, it is important that you do not leave here
with misconceptions: a lot of the tests you will be writing, might not be unit tests – they are integrated
tests. These are tests where you allow other classes and objects to interact with your unit under test
and potentially influence the outcomes of those tests. The issue here is that a test that fails on one
class might be reacting to a bug in another class – reducing the ability of your tests to identify the
location of a bug. Again, we will not be solving this issue this semester, but you should look forward
to being able to separate a single unit in the future, and remember that until you do so you are not
writing true ’unit’ tests.
Software Design and Construction 1 Page 3 of 3
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com