EVOLUTION-MANAGER
Edit File: test.html
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><title>R: Test assertions for equality, exceptions and console output</title> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <link rel="stylesheet" type="text/css" href="R.css" /> </head><body> <table width="100%" summary="page for test {data.table}"><tr><td>test {data.table}</td><td style="text-align: right;">R Documentation</td></tr></table> <h2> Test assertions for equality, exceptions and console output </h2> <h3>Description</h3> <p>An internal testing function used in <code>data.table</code> test scripts that are run by <code><a href="test.data.table.html">test.data.table</a></code>. </p> <h3>Usage</h3> <pre> test(num, x, y = TRUE, error = NULL, warning = NULL, message = NULL, output = NULL, notOutput = NULL, ignore.warning = NULL) </pre> <h3>Arguments</h3> <table summary="R argblock"> <tr valign="top"><td><code>num</code></td> <td> <p> A unique identifier for a test, helpful in identifying the source of failure when testing is not working. Currently, we use a manually-incremented system with tests formatted as <code>n.m</code>, where essentially <code>n</code> indexes an issue and <code>m</code> indexes aspects of that issue. For the most part, your new PR should only have one value of <code>n</code> (scroll to the end of <code>inst/tests/tests.Rraw</code> to see the next available ID) and then index the tests within your PR by increasing <code>m</code>. Note – <code>n.m</code> is interpreted as a number, so <code>123.4</code> and <code>123.40</code> are actually the same – please <code>0</code>-pad as appropriate. Test identifiers are checked to be in increasing order at runtime to prevent duplicates being possible. </p> </td></tr> <tr valign="top"><td><code>x</code></td> <td> <p> An input expression to be evaluated. </p> </td></tr> <tr valign="top"><td><code>y</code></td> <td> <p> Pre-defined value to compare to <code>x</code>, by default <code>TRUE</code>. </p> </td></tr> <tr valign="top"><td><code>error</code></td> <td> <p> When you are testing behaviour of code that you expect to fail with an error, supply the expected error message to this argument. It is interpreted as a regular expression, so you can be abbreviated, but try to include the key portion of the error so as not to accidentally include a different error message. </p> </td></tr> <tr valign="top"><td><code>warning</code></td> <td> <p> Same as <code>error</code>, in the case that you expect your code to issue a warning. Note that since the code evaluates successfully, you should still supply <code>y</code>. </p> </td></tr> <tr valign="top"><td><code>message</code></td> <td> <p> Same as <code>warning</code> but expects <code>message</code> exception. </p> </td></tr> <tr valign="top"><td><code>output</code></td> <td> <p> If you are testing the printing/console output behaviour; e.g. with <code>verbose=TRUE</code> or <code>options(datatable.verbose=TRUE)</code>. Again, regex-compatible and case sensitive. </p> </td></tr> <tr valign="top"><td><code>notOutput</code></td> <td> <p> Or if you are testing that a feature does <em>not</em> print particular console output. Case insensitive (unlike output) so that the test does not incorrectly pass just because the string is not found due to case. </p> </td></tr> <tr valign="top"><td><code>ignore.warning</code></td> <td> <p> A single character string. Any warnings emitted by <code>x</code> that contain this string are dropped. Remaining warnings are compared to the expected <code>warning</code> as normal. </p> </td></tr> </table> <h3>Value</h3> <p>Logical <code>TRUE</code> when test passes, <code>FALSE</code> when test fails. Invisibly. </p> <h3>Note</h3> <p><code>NA_real_</code> and <code>NaN</code> are treated as equal, use <code>identical</code> if distinction is needed. See examples below. </p> <p>If <code>warning=</code> is not supplied then you are automatically asserting no warning is expected; the test will fail if any warning does occur. Similarly for <code>message=</code>. </p> <p>Multiple warnings are supported; supply a vector of strings to <code>warning=</code>. If <code>x</code> does not produce the correct number of warnings in the correct order, the test will fail. </p> <p>Strings passed to <code>notOutput=</code> should be minimal; e.g. pick out single words from the output that you desire to check does not occur. The reason being so that the test does not incorrectly pass just because the output has slightly changed. For example <code>notOutput="revised"</code> is better than <code>notOutput="revised flag to true"</code>. <code>notOutput=</code> is automatically case insensitive for this reason. </p> <h3>See Also</h3> <p><code><a href="test.data.table.html">test.data.table</a></code> </p> <h3>Examples</h3> <pre> test = data.table:::test test(1, x = sum(1:5), y = 15L) test(2, log(-1), NaN, warning="NaNs") test(3, sum("a"), error="invalid.*character") # test failure example stopifnot( test(4, TRUE, FALSE) == FALSE ) # NA_real_ vs NaN test(5.01, NA_real_, NaN) test(5.03, all.equal(NaN, NA_real_)) test(5.02, identical(NaN, NA_real_), FALSE) </pre> <hr /><div style="text-align: center;">[Package <em>data.table</em> version 1.14.4 <a href="00Index.html">Index</a>]</div> </body></html>