Mutation testing is a technique to detect bugs in a program by changing its source code (called "mutation") and checking whether the program's test suite detects this mutation. The mutations are designed to mimic typical programming errors (e.g., off-by-one errors). If such errors are not noticed by the test suite, the "survived" mutation can be used to create an additional test that would detect it.
Mutate++ is a mutation test environment for C++ programs. It supports you with the following tasks:
Mutate++ is a web app that runs locally on your machine. All computation is locally, and no data is shared with anyone.
You need Python 3 which can be downloaded here or installed by your operating systems's package manager.
After checking out the sources from this repository, you need to create a virtual environment and install the required packages:
virtualenv -p python3 venv venv/bin/pip install -r requirements.txt
Next, we need to create a database where mutations and the results are stored:
The database file is an SQLite3 database
app/app.db. You can then run the app with
and open it in your browser with the URL http://127.0.0.1:5000.
We use a small example project to demonstrate the required steps to set up a project in Mutate++. We assume that you have git, CMake, make, and a C++ compiler installed.
Mutate++ will run the following (simplified) workflow:
We now set up the project so that we can build and test the project ourselves.
cd /tmp git clone https://github.com/bast/cmake-example.git cd cmake-example mkdir build cd build cmake ..
We now have two directories we will be referring to later:
/tmp/cmake-example/build: this is the directory where we will execute the build and test commands
/tmp/cmake-example/src: this is the directory with the source code
Let's try building and testing:
cd /tmp/cmake-example/build make ctest
We see that 100% of the tests passed.
In the following, we shall refer to these commands as:
make: this is the command that builds the project from source
ctest: this is the command that executes the test suite
Example projectas project name.
/tmp/cmake-example/buildas working directory.
makeas build command.
ctestas test command.
Note that we assume the build and test command to succeed if they end with exit code
0. This is the default for most
tools like CMake, CTest, Ninja, etc.
We are now in the project overview and see the workflow Mutate++ will execute, consisting of the steps "build" and "test". We see that no files have been added yet, and also the patches overview is empty.
Back in the project overview, you see that 14 patches have been generated. You can inspect them back clicking on "14 patches" in the "Patches" section. In this overview, you see the individual patches with their line, kind, state and confirmation:
Let's now click on "4" to have a look at the details of a patch:
return f1 + f2;by
return f1 * f2;.
Go back to the project overview.
Now it is time to actually apply the patches:
What happened? Mutate++ executed the workflow described above for each patch. That is, it applied the patch to the
/tmp/cmake-example/src/example.cpp, executed the build command
make in the working directory
/tmp/cmake-example/build, and then executed the test command
ctest in the same directory. As we have a trivial
project with just 14 patches, this is just a matter of seconds.
The Patches second got more colorful now. We see a graph that describes the breakdown of the patches:
In the patch overview, we see what happened:
/tmp/cmake-example/src/example.cpp, resulting in function
multiply_numbersnot returning anything.
Why is this an issue? Because no one noticed that we deleted the multiplication! The easiest way to fix this is by adding a respective test case. In larger projects, we do not want to switch back and forth between evaluating patches and fixing the test suite, so we set the patch "confirm" and press "Submit".
In some cases, the patch would change the source code in ways that it is natural that the test suite would not
detect it, e.g. in parts of the code that are skipped by preprocessor directives (e.g. with
#ifdef commands) or when,
the patch results in equivalent code. In that cases, set the patch to "ignore".
Later, you can filter to show only the confirmed patches and adjust your test suite accordingly.
In the project overview, you also get some statistics on the execution: We see that 5 patches failed during the build, whereas 9 built successfully. From these 9, 8 failed the tests, and 1 patch succeeded.
make cleancommand, but adding this as clean command would only increase the build times, because all source files would be re-compiled even if only one was changed.
Mutate++ is in a very early stage, and there is a lot to do. In particular, we are aware of severe limitations:
That said, pull requests and issues are more than welcome!
Mutate++ contains the following libraries for the frontend:
Mutate++ is licensed under the MIT License:
Copyright © 2017 Niels Lohmann
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.