# Automating Testing of Mathematica Code

I'm getting started with unit testing of Mathematica code and looking for information on fitting this into an automated testing environment.

For example with Node.js I write some code and tests and then hook it up with a testing pipeline. So when I check in my changes, Jenkins gets the changes, runs the tests and publishes the results (and possibly other things like build artifacts or build documentation, but this is the simplest case).

From the Mathematica documentation I'm having a hard time figuring out how to do two important steps here.

First, everything I see about testing in Mathematica talks about testing and seeing the results in a notebook. For automated testing by a build server the tests would have to be run without a notebook with just a command line interface.

Second, the test report would need to be in some type of format that could be consumed by Jenkins (or some other build server). This could be one of various different formats but I don't see how to export the test results.

• I doubt you would get a simple answer. Mathematica does not have the same facilities as say Visual Studio. There is some integration with Eclipse but it is far from good (IMO). Search for Wolfram Workbench. – Hector Jan 17 '18 at 19:39
• @Hector I don't think it should need any integrations with an IDE or something like that. Most build servers just need a way to run all the tests from the shell and output the report in some format. – Sean Lynch Jan 17 '18 at 19:47
• In the comparison with Visual Studio, I had their testing tools in mind. You might want to check this answer. As for writing output to files, You can use Export. – Hector Jan 17 '18 at 19:57
• AFAIK there is nothing ready to use but it should certainly be possible to build something. I would suggest to save the testing-notebooks as .wlt files (or directly write your tests in that format). You could then use a simple Mathematica script like Print[TestReport["path/to/testfile.wlt"]@"AllTestsSucceeded"] and run that from the command line. Once you have that running it shouldn't be too difficult to start that script from Jenkins or comparable software... – Albert Retey Jan 17 '18 at 22:31
• @AlbertRetey I was looking into this more today and started to think along the lines of your idea. This should be put into an answer. – Sean Lynch Jan 17 '18 at 23:30

## 1 Answer

I am not aware of something ready to use for fully automated testing of Mathematica code, but the building blocks for that are available in newer Mathematica versions.

The following is just a rough description of the steps necessary for such a setup. As I think it would be valuable to have a more detailed recipe for such a setup I made this a community wiki, so everybody is welcomed to fill in the details...

Here are the steps I think would be necessary:

## Create testfiles

You can either convert testing-notebooks to *.wlt files (using the "More" -> "Save as .wlt" menu in the Testing-Notebook docked cells), write .wlt files directly or also write "old-style" .mt files for MUnit (for the latter you would also need to ensure the package is available). Here is a very minimal example of .wlt file content.

BeginTestSection["AutomatedTests"]
VerificationTest[Plus[1, 1],2]
EndTestSection[]


## Create a "driver" script

Create a .m file or probably better a .wls script which runs the tests and prints or returns the outcome of the tests. A very simplified first step would be something like:

Print[TestReport["/path/to/testfile.wlt"]@"AllTestsSucceeded"]


## Start driver script from command line

Ensure you can run the above file from the command line. Depending on your preferences and OS you might want to write a shell-script to do that. Using a .wls script and Exit[returncode] you should be able to do everything you need from within the wolfram script, though...

## Configure a test automation tool

For the automation I would suggest to install the test automation tool of your choice and configure it to run the above script on the given events (e.g. a checkin or push to a version control system). You might need to adopt the driver script so that the tool can understand the outcome of it.