Transcripted Summary
So now that youāve written your first set of tests, let's look at how to calculate code coverage using IntelliJ's built-in code coverage tool.
Let's go back to our first test, the one that we just used to create a new object, and just make sure that we could store that information.
public class CustomerTest {
/**
* The system should be able to store information on a new customer using valid data.
* Scenario:
* 1. Given I create a new customer named Mickey Mouse
* 2. When I initialize the customer object with valid details.
* 3. Then Mickey's information should be stored in the system.
*/
@Test
public void creatingCustomerWithValidData_StoresSpecifiedData() {
// Given and When
Customer customer = new Customer("Mickey Mouse", "Disneyland", "Mickey@Disneyland.com");
// Then
assertNotNull(customer);
assertEquals(customer.getName(), "Mickey Mouse");
assertEquals(customer.getAddress(), "Disneyland");
assertEquals(customer.getEmail(), "Mickey@Disneyland.com");
}
Recall that we just invoked the instructor and pass the information in, and then we did some assertions. Many of the assertions just retrieved the information from the object and compare the expectations. So, they just use the get method.
If we run this particular test in code coverage mode by selecting ārun āscenarioā with coverageā, we'll start to see the code coverage metrics that are calculated.
We'll start to see at the package level, where we are looking at the āBankServiceā package, and we can see the total percentage of classes that are covered within the package. Similar, methods within the package, and then actual lines of code.
So here, this particular test is only contributing six percent of coverage towards the total lines of code. That is 8 out of 120 lines.
Now we can drill into this and go specifically to the customer class because we don't have coverage for anything else.
We can see that 58% of that class is covered in terms of the lines of code, and in terms of the methods. Then we have 100% of the class level for that particular class because we did test it at least once.
Once we start looking at code coverage, always remember that this is not a means to an end.
We're not trying to just achieve 100% and then stop.
Let's drill into this particular class, and we can see that the tool actually highlights the areas that were covered in green.
And these were lines that weren't covered by that test in red. We can see that these lines that aren't covered are all around āupdateā, but our second test was the around āupdateā.
So, let's run these two together and see if we get 100% line coverage.
So here you go at the class level which will run all of these scenarios, and you ārun the āCustomerTestā with coverageā. It should prompt you to see if you want to replace that active dialogue within your results. So, we can do that.
Here now we see that these tests actually contribute a little bit more, 11% of line coverage. But let's drill to Customer.
Customer actually has 100% coverage all across, all 14 lines. We can look at that and see that indeed, you've covered the constructor, the getters, and the setters.
So, that's the basic introduction to code coverage.
**But always remember that even though we have 100% coverage, it doesn't mean that we have strong tests.** There is still a lot of different values that we could throw out this application. But because this application is designed by contract, we'll not get into negative testing and calling out that maybe the cases were handling bad inputs or not there.
Resources
Quiz
The quiz for Chapter 4 can be found at the end of Section 4.4
