lab03 : Testing and Test Case Coverage

num ready? description assigned MW lect due MW lect assigned TR lect due TR lect
lab03 true Testing and Test Case Coverage Tue 01/21 11:00AM Wed 01/29 11:59PM Wed 01/22 12:30PM Wed 01/29 11:59PM

https://ucsb-cs56.github.io/w20/lab/lab03

READY: Except for the Gradescope autograder; that should be ready by 5pm Tuesday 01/21

lab03

In this lab:

Working in a pair? Switch navigator/driver frequently and tradeoff who commits

If you are in your repo directory, and type git log at the command line, you’ll see a list of the commits for your repo.

Record that you are pairing on each commit message by putting the initials of the pair partners at the start of the commit message.

E.g. If Selena Gomez is driving, and Justin Timberlake is navigating, and you fixed a bug in your getDanceMoves() method, your commit message should be SG/JT fixed bug in getDanceMoves()

We should see frequent switches between SG/JT and JT/SG.

Step-by-Step

Step 0: Set up your repo

You may work individually or as a pair on this lab. However, if you work as a pair, please:

If there is some reason this is not feasible, please check with your mentor before starting.

Create your repo the same way you did for lab01

Clone this empty repo into your ~/cs56 directory, or wherever you prefer to work.

The starter code is in https://github.com/ucsb-cs56-w20/STARTER_lab03. Visit that page for the approrpiate URL to add the starter remote.

To add the starter as a remote, cd into the repo you cloned, then do:

git remote add starter https://github.com/ucsb-cs56-w20/STARTER_lab03

Then do:

git pull starter master
git push origin master

That should get you set up with the starter code.

Step 1: Get oriented to using Maven instead of Ant

A few things to notice:

Don’t change the package from pconrad to your name; the Gradescope autograder is looking for the code under the edu.ucsb.cs56.pconrad.menuitems package. So each source file:

Here are the commands you’ll need as you work with the code. Try them out now.

To do this Type this command Notes
compile the code mvn compile  
reset everything mvn clean  
run the tests mvn test  
generate javadoc mvn javadoc:javadoc site site:deploy  
generate javadoc and copy into docs directory for GitHub pages mvn javadoc:javadoc site site:deploy  
generate a report of test coverage mvn test jacoco:report Open the file target/site/jacoco/index.html in a browser to read the report
generate a jar file mvn package  

Step 2: Start writing code to make tests pass

In this lab, you’ll be implementing several methods of a class called MenuItem that represents item on a restaurant Menu.

(There is a follow up lab in which we will add a Menu class that uses these menu items; but we need to discuss sorting, java.lang.Comparable, java.util.Comparator, and Java lambda expressions in lecture first before we get to that.)

A MenuItem represents an item on the menu of a restaurant. It has three attributes:

Note that the starter code:

YOU WILL NEED TO WRITE SOME OF YOUR OWN TESTS.

So you’ll need to do a bit more work than you may be used to.

I suggest that you work in this order:

Details about methods of MenuItem

The constructor has the signature:

public MenuItem(String name,
                int priceInCents,
                String category)

Here are the instance methods you’ll need to implement for MenuItem

Modifier and Type Method Description
String getCategory() Returns the category of the menu item
String getName() Returns the name of the menu item
String getPrice() Returns the price, formatted as a string with a $.
String getPrice(int width) Returns the price, formatted as a string with a $, right justified in a field with the specified width.
int getPriceInCents() get the price in cents only
String toString() return a string in csv format, in the order name,price,cateogry.
For example: "Small Poke Bowl,1049,Poke Bowls"
In this case, the price is unformatted; just an integer number of cents.

Step 3: Learning about Test Coverage

Now, did you really write unit tests for all of your code? Let’s check!

We can automatically compute “test case coverage”, using a tool call JaCoCo (Java Code Coverage).

Read these short articles about test coverage before moving to step 4:

Once you’ve looked over those, it’s time to check your test coverage, which we’ll do in Step 4.

Step 4: Checking Test Case Coverage

Be sure that you’ve added your pair partner to your submissions on Gauchospace

Then, check your test coverage:

Some of the points in the manual inspection may be awarded on the basis of having good test coverage.
While 100% test coverage is not always the goal, in this particular exercise, it should be possible.

So if you see that you don’t have 100% test coverage, go back and write some additional unit tests.

How to read the test coverage reports

Step 5: Try to get as close to 100% coverage as you can

Keep reworking your code until you get as close as you can to 100% test coverage.

As we’ll discuss in lecture, 100% coverage isn’t always necessary or even desirable, but in this case you should be able to get there, or at least pretty close.

One method that it’s definitely ok to not have test coverage for (in this particular project) is the public static void main(String [] args) method; that method is only there as a placeholder, and contributes nothing to the correctness of the code. If it did, we’d need to consider writing tests for it (and that is possible, though a little awkward.)

Resubmit on Gradescope once you’ve gotten as close to 100% as you think you can get.

If there are lines of code that are NOT coverage by tests, add some explanation in your README.md as to why it wasn’t feasible to test those lines of code.

Step 6: Before final submission on Gradescope

Troubleshooting

If you get this message from Gradescope:

Could not locate expected jar file to run unit tests: 
target/menuitem-1.0-fat-tests.jar

what that actually means is that autograder was not able to compile the instructor tests against your solution.

That is probably because your solution does not yet contain stubs for one or more of the required methods.

For example, if you don’t implement stubs for the getPriceInCents() or the getCategory() methods before you submit to Gradescope, then you’ll probably get the message about the target/menuitem-1.0-fat-tests.jar being missing.

You have to implement stubs for all of the specified functions before you will get test results for any of them on Gradescope. So writing those first is a really good plan.

End of description for lab03