Whether you are using your own code, someone else's code or a open source software package like lammps or hoomd, you should always do thorough testing whenever you are using or implementing a new feature. Hoomd-blue has a whole suite of tests it can perform for you when you install it. These tests are called unit tests, because they perform per-defined tests on the level of units (e.g. functions/classes/modules). Every developer or maintainer adds a unit test for the feature or function they implemented. They are usually small and can be executed automatically, like hoomd-blue does:

cd <path-to-your-hoomd-blue-repository>
cd build
make test

You will see a whole bunch of tests if you did not disable the testing during the cmake step (-DBUILD_TESTING) during the compilation. azplugins have the same structure and unit tests can be executed in the same way. If there is a specific unit test which is failing, you can use

ctest -V -R test_name

to get more detailed feedback on what is going wrong, where -V stands for verbose and -R only executes the tests matching the regular expression after it, in this case it's the full name. you could also just execute all tests ending with cpu : ctest -V -R *-cpu.

(https://lammps.sandia.gov/doc/Build_development.html#code-coverage-and-unit-testing|Lammps)) also has its on set of unit tests, executed with ctest as well.

Whenever you compile a code with unit tests someplace new, or you update the version, or implement something, you should re-execute the unit tests. If you are on the cluster, you might need to submit a job requesting the needed resources (e.g. a GPU) to successfully complete the unit tests.

The unit tests are also automatically performed on github with CircleCI and you can see the overall status of the performed tests on branches and merge requests.

Whenever you are implementing a new feature or develop an algorithm, you should be doing unit testing as a part of the development cycle. Doing so will not only ensure that your code is correct, it will also make you think about what are the expected inputs or parameters and outputs of a new feature. The unit test is also an example on how to use this feature. Most tests for hoomd-blue are on the python level and they are located in sub-folders called test-py and you can use the unit tests of a similar feature as a starting point to develop your own. It is difficult to give general guidelines because the tests depend on the feature, but it is good to think about these questions:

• Can the object be created and destroyed?
• What are parameters which need to be provided by the user? What is supposed to happen if the user does not provide them or provides a wrong type ? Are there default values, can the be left blank or do I need to throw an error?
• Do my set_parameter() and get_parameter()-type of functions work, if I have them?
• Does my code work with MPI/CUDA? If not, make sure it is excluded from those and that it either gives a warning or error where appropriate.
• If I calculate the expected behavior in a certain situation by hand, does this match with the output of the code? (E.g. pair potential value at a certain distance, position and velocity after a collision, ..)
• Does my feature need to notify or be notified if things change during the simulation (e.g. what happens if the box size changes? Particle types?)
• Is there an existing part of the code (module or feature) you know is incompatible or untested with your new feature? If so is there a error implemented to guard against the usage of the incompatible parts?

The unit tests only test each class/component, they don't test if your models make sense, if your parameters are chosen correctly, if your initial condition is correct, etc. There can still be many undiscovered bugs in the code as well.

For this, it is often useful to start with a minimal working example, and go from there.

https://github.com/lammps/lammps/labels/bug https://github.com/glotzerlab/hoomd-blue/issues

https://lammps.sandia.gov/mail.html

https://groups.google.com/forum/#!forum/hoomd-users

• Beginner friendly introduction: https://www.codementor.io/@wbsimms/unit-testing-foundations-programming-beginners-du107q81d
• python unittest (used by hoomd and azplugins): https://docs.python.org/3/library/unittest.html https://www.journaldev.com/15899/python-unittest-unit-test-example
• https://www.guru99.com/unit-test-vs-integration-test.html