Write Test Scripts

If you write your code in collaboration with other developers or intend to extend or update it later, you need to test your code more than once. Testing a part of code every time when you or somebody else change it helps you ensure that this part works properly. When you plan to test some part of code repeatedly, it is helpful to write a test script and execute it every time when you need to test the code. For example, create the following procedure f. This procedure accepts two numeric arguments, a and b, compares them, and returns the larger number:

f := proc(a:Type::Numeric, b:Type::Numeric)
begin
  if a = b or a > b then
    return(a)
  else
    return(b)
  end_if
end_proc:

Suppose you will likely update this procedure in the future. To ensure that the procedure works as expected after all possible updates, write the test script and execute it after any update. The test script in MuPAD® includes a set of single tests created by the prog::test function. See Writing Single Tests for more information.

Each test script starts with the prog::testinit function and ends with the prog::testexit function. To specify the name of the tested procedure, use print(Unquoted, "testname") after prog::testinit. This name does not affect the tested procedure itself. It only appears in the test reports generated by your test script.

To test the procedure f for different choices of parameters, write the following test script and save it to the test-f.tst file. The test does not find any unexpected results or errors. After MuPAD executes the test script, it generates the test report. The test script does not require any particular file extension. You can use any file extension that you like. The test report shows the number of executes tests, the number of errors encountered while executing the test script, and the time and memory used to execute the test script:

//test-f.tst
prog::testinit("f");
print(Unquoted, "function f that compares two numbers")

prog::test(f(1, 1), 1):
prog::test(f(1, 2), 2):
prog::test(f(2, 1), 2):
prog::test(f(100, 0.01), 100):
prog::test(f(0.01, 100), 100):
prog::test(f(-10, 10), 10):
prog::test(f(2*I, 2*I), 2*I):
prog::test(f(2 + I, 2 + I), 2 + I):
prog::test(error(f(2 + I, 3 + I)), TrapError=1003):
prog::test(error(f(x, y)), TrapError=1202):
prog::test(error(f(x, x)), TrapError=1202):

prog::testexit(f)
Info:
11 tests, 0 errors, runtime factor  0.0  (nothing expected)
Info: CPU time:  12.7 s
Info: Memory allocation 20452460 bytes [prog::testexit]

If you change the original procedure f, run the test script to catch any unexpected results:

f := proc(a:Type::Numeric, b:Type::Numeric)
begin
  if a >= b then
    return(a)
  else
    return(b)
  end_if
end_proc:

You do not need to copy the test script to the notebook. Instead, you can execute the test script that you saved to a file without opening the file. To execute a test script:

  1. Select Notebook > Read Commands to open the Read Commands dialog box.

  2. Change the file filter to show MuPAD test files or all files.

  3. Navigate to the test file that contains the script and click OK.

Alternatively, use the READPATH variable to specify the path to the folder that contains the file. Then use the read function to find and execute the test file. For example, if you saved the test file test-f.tst in the folder C:/MuPADfiles/TestScripts, use the following commands:

READPATH := "C:/MuPADfiles/TestScripts":
read("test-f.tst")
Error
in test function f that compares two numbers 7
Input: f(2*I, 2*I)
Expected:
 2*I
Got:       TrapError = [1003,
"Error: Can't evaluate to boolean [_leequal];\r\n  Evaluating: f"]
Near line: 9

Error in test function f that compares two
numbers 8
Input: f(2 + I, 2 + I)
Expected:  2 + I
Got:
      TrapError = [1003, "Error: Can't evaluate to boolean [_leequal];\r\n
 Evaluating: f"]
Near line: 10

Info: 11
tests, 2 errors, runtime factor  0.0  (nothing expected)
Info: CPU time:  12.7 s
Info: Memory allocation 20452460 bytes [prog::testexit]

Although the change seems reasonable and safe, the test report shows that the procedure does not work for equal complex numbers anymore. Instead, the procedure throws an error. If you do not test the code, you can miss this change in procedure behavior. If this behavior is expected, correct the test script. Otherwise, correct the procedure.

Was this topic helpful?