Anonymous user
Test a function: Difference between revisions
Add source for Rust
m (→{{header|Phix}}: better descs) |
(Add source for Rust) |
||
Line 82:
with Post => Palindrome'Result =
(Text'Length < 2 or else
=={{header|AutoHotkey}}==
Line 1,907:
Test run options: --seed 40770</pre>
=={{header|Rust}}==
Rust supports two ways of writing unit tests out of the box. Most tests are written
as functions with <code>#[test]</code> attribute. When running <code>cargo test</code>
(Cargo is the build and package manager), these functions are executed. The test
functions are usually placed in a separate module and excluded from regular builds;
as the example shows, the whole module with tests has <code>#[cfg(test)]</code>
attribute which has this effect.
The other way is using documentation comments. The documentation can contain code
snippets and <code>rustdoc</code> (or <code>cargo</code>) compiles and runs these
code snippets as tests (it is possible to specify the expected outcome, including
the situation that the snippet should fail to compile). Note that the documentation
tests work for libraries only (as for Rust 1.46) and are not run for binary crates.
In either case, the tests are supposed to use <code>assert!</code> macro (and its
variants <code>assert_eq!</code> and <code>assert_ne!</code>) to check the expected
outcomes. These macros can be used in regular code as well and always execute. When
an assertion should be checked in debug builds only, <code>debug_assert!</code> and
its variants can be used instead.
<lang Rust>/// Tests if the given string slice is a palindrome (with the respect to
/// codepoints, not graphemes).
///
/// # Examples
///
/// ```
/// # use playground::palindrome::is_palindrome;
/// assert!(is_palindrome("abba"));
/// assert!(!is_palindrome("baa"));
/// ```
pub fn is_palindrome(s: &str) -> bool {
let half = s.len();
s.chars().take(half).eq(s.chars().rev().take(half))
}
#[cfg(test)]
mod tests {
use super::is_palindrome;
#[test]
fn test_is_palindrome() {
assert!(is_palindrome("abba"));
}
}</lang>
While unit tests are written together with the tested code (and thus may employ the
white-box test approach), the code may be accompanied yet with integration tests,
conventionally provided in the <code>tests/</code> folder. Integration tests are
considered external and use the public interface as any other external code.
=={{header|Scala}}==
Line 2,067 ⟶ 2,118:
tcltest::cleanupTests</lang>
If placed in a file called <tt>palindrome.test</tt>, the following output is produced when it is executed:
<pre>palindrome.test:
Note that only a small fraction of the features of the testing framework are demonstrated here. In particular, it does not show off management of conditional execution, the application of setup and cleanup code, and how these things are assembled into a whole test suite for a large system.
| |||