Mutation Testing Systems: Improving the Quality of Tests

Mutation Testing Systems: Improving the Quality of Tests

See why mutation testing might be the answer for better quality tests and thus higher quality code.

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 to get the test coverage report and the result is as follows.

Work time reports

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.

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

Bootstrap 5 Complete Course with Examples

Bootstrap 5 Tutorial - Bootstrap 5 Crash Course for Beginners

Nest.JS Tutorial for Beginners

Hello Vue 3: A First Look at Vue 3 and the Composition API

Building a simple Applications with Vue 3

Deno Crash Course: Explore Deno and Create a full REST API with Deno

How to Build a Real-time Chat App with Deno and WebSockets

Convert HTML to Markdown Online

HTML entity encoder decoder Online

Offshore Software Development - Best Practices

To make the most out of the benefits of offshore software development, you should understand the crucial factors that affect offshore development.

Is Software Testing a Good for Career?

Software testing training in noida provided by CETPA. Searching for best and recognised advanced Software testing Course in Noida, then enrol with ‘CETPA .

5 Core Criteria for Selecting Software Development Company - TopDevelopers.co

Check out these five criteria for the selection of your software vendor, and you will never regret having the wrong quality product made for you.

ERP Software Services, POS Software Services , Application Development

Vinew Technologies focused majorly over ERP Software services and POS Software services, Web & Application development services & Woo commerce and Wordpress easy-to-use, multipurpose social media plugin for WordPress.

Learn Software Testing Course in Delhi - APTRON Solutions

Many institutes are having a Software Testing Training And Placement In Delhi but few of them are very great at teaching. In the event that you want to learn about software testing. We have designed this software testing training course to learn...