Professionally, I label myself as a developer, although I don’t like labels very much, and I prefer to say that the reason for my work is: to create quality software. But what is quality software? I like to define it as follows:
Quality software is that which meets the user’s needs
efficiently and without errors.
I could add more adjectives, go into detail why needs and not requirements… but for me, that would be the definition. However, it’s difficult to get quality software if it’s not written with quality code.
Quality Software → Quality Code
Fortunately, developers are not alone in this task. There are tools for static code analysis (Checkstyle, PMD, FindBugs, SonarQube…) and different recommendations for good practices (personally I would highlight Clean Code and The Pragmatic Programmer). And there among proposals, acronyms, =and metrics, there’s no developer that doesn’t directly associate the term quality with the term testing (right?)
Quality code → Quality tests
Testing: the Path to Quality
Tests are as important to the health of a project as the production code is.
Clean Code. Chapter 9: Unit Tests
There are several types of tests (unit, integration, acceptance…). The most widespread are unit tests and integration tests. With them you get a certain perception of security, since although we do not know if the code does what it should, at least it does what it says.
But is this so? Paradoxically, this practice consists of generating more code. So we continue programming, but who says this code does what it says? That is, who watches over the quality of the tests? Again another association of terms: quality tests are those that offer a high % of code coverage.
Quality tests → High % coverage of our code
A higher percentage of code coverage gives better tests and more reliable code. This is nothing new. If I talk from my personal experience, a few years ago (back in the early 2000s) the minimum % coverage requirement was part of the delivery specifications of some projects. “This deliverable must have a battery of tests that ensure a minimum of 70% code coverage”, as a synonym of error-free code and proven quality in at least 70% of the code.
Taking as an example an application to check the hours (or part hours) worked, let’s imagine that we are developing a method that, given a worker and a day, checks the status of the worker’s time sheets on that day (whether or not he has done the required hours, if he has done extra time…).
Java
@Override
public DayStatusSummary getDayStatusSummaryForWorkerAndDay(String workerUserName, LocalDate date) {
DayStatusSummary status = new DayStatusSummary();
status.setDate(date);
status.setWorkerUserName(workerUserName);
List worklogsForDay = worklogRepository.findByUsernameAndDate(workerUserName, date);
int totalDuration = 0;
for (Worklog worklog : worklogsForDay) {
totalDuration = totalDuration + worklog.getDuration();
}
if (totalDuration == 8) {
status.getStatusList().add(DayStatus.RIGHT_HOURS);
if (totalDuration > 8) {
status.getStatusList().add(DayStatus.EXTRA_HOURS);
}
if (totalDuration < 8) {
status.getStatusList().add(DayStatus.MISSING_HOURS);
}
return status;
}
Let's see an example of tests that we submitted at the time:
Java
@Test
public void get_status_summary_for_worker_and_day() {
reportsService.getDayStatusSummaryForWorkerAndDay(“USU”, LocalDate.now());
assertTrue(true);
}
@Test
public void calculates_the_status_based_on_worker_and_date_worklogs() {
List<Worklog> partes = new ArrayList<Worklog>();
Worklog wl = new Worklog();
wl.setFromTime(LocalTime.of(8,0,0));
wl.setToTime(LocalTime.of(19,0,0));
partes.add(wl);
Mockito.when(worklogRepository.findByUsernameAndDate(ArgumentMatchers.anyString(),
ArgumentMatchers.any(LocalDate.class))).thenReturn(partes);
LocalDate fecha = LocalDate.now();
reportsService.getDayStatusSummaryForWorkerAndDay("USU", fecha);
Mockito.verify(worklogRepository).findByUsernameAndDate(“USU”, fecha);
}
```
We configured [JaCoCo](https://www.eclemma.org/jacoco/) to get the test coverage report and the result is as follows.
We have a coverage of 92% of lines and 87% of branches: objective met. But...if you look: the first test will (almost) never fail because it always ends with `assert true`, the second is a bit “more complete” because at least it verifies that the hours (or part hours) are retrieved...
If you want to try all this then download the code from [Github](https://github.com/wearearima/time-report-app/tree/feature/01_tests_for_project_requirements).
Well, this was my reality, and I am very much afraid that it was THE reality of that time in many projects (and who knows if in some of today). The projects met the code coverage requirements, which was far from having quality software.
It’s true that the example I have given is extreme, but it is real. In my opinion, the problem is in the focus: everything has been turned around, and the tests are created as a mere tool to fulfill one of the requirements of the project.#test #software developent #software quality #mutation testing #coverage #test quality #pitest
