关键词 > SOFT2201/COMP9201
SOFT2201/COMP9201 Week 11 Tutorial
发布时间：2023-02-09
Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: daixieit
SOFT2201/COMP9201
Week 11 Tutorial
Software Testing
Programmatic Code Testing
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?"
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.
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
jacoco {
toolVersion = "0 .8 .8"
reportsDir = file("$buildDir/customJacocoReportDir") }
jacocoTestReport {
reports {
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.
