In this way, the test runner not only determines how unit tests will be written, but it actually determines the programming language used in the tutorial.

* #"diff-3f0a052b44acfd92a825dcef177c9f9bfadf3f9cf904f3d94c2418a8a4fd7a47-16-16-0" data-selected="false" role="gridcell" tabindex="-1" valign="top">

* #"diff-3f0a052b44acfd92a825dcef177c9f9bfadf3f9cf904f3d94c2418a8a4fd7a47-16-17-0" data-selected="false" role="gridcell" tabindex="-1" valign="top">

* Python:[*pytest-coderoad*](//github.com/coderoad/pytest-coderoad)

We need more test runners. Why not build one?

See a brief example from the[*mocha-coderoad* runner](https://github.com/coderoad/mocha-coderoad/blob/master/src/runner.ts), as well as a code summary below:

exportdefaultfunctionrunner(testFile,config,handleResult) {

exportdefaultfunctionrunner({testString, config, handleResult}) {

handleResult(result);// returns test result

}

Also notice that the runner in the above example handles any`console.log` statements. A special character string is added before the result, any data without that match is passed to the log.

`console.dir` is used to make objects & arrays more accessible in the console.

if (!match) {

try {

console.dir(JSON.parse(JSON.stringify(data)));

console.log(data);

}catch (e) {

console.log(data);

}

return;

}

Let's look at these three test runner inputs in more detail.

Let's look at these three test runner keys that are passed into the runner as an object:

The absolute path to a file containing all concatenated pagetests. Call your test framework with this file path.

A string with all test input. This includes unittests, the user input from the text editor, and some helper functions behind the scenes.