11 - tests

Question 1

How to make sure that a test function panics with a specific panic message?

Answer 1

add:
#[should_panic(expected = "panic because...")]
before function signature.

Question 2

How to make a test fail if it returns an Err(error)?

Answer 2

Add return type to the function signature like so:
#[test]
fn test_func() -> Result

*You can change String to the desire error type

Question 3

By default, how many threads would run by calling “cargo test”?

Answer 3

By default, any test run in parallel, each test runs in its own thread.

Question 4

How can we run test serially?

Answer 4

We can run test serially with the following command:
cargo test – –test-threads=1

*test-threads is an argument given to the resulting binary

Question 5

How to show stdout output of a test function?

Answer 5

run:

cargo test – –show-output

Question 6

How can you run a specific test? how can you run a specific test module?

Answer 6

run:
cargo test test_function_name

cargo test test_module_name::

*you can also specify part of the name, and all the function that match the pattern will be tested

Question 7

How can you ignore a specific test? how can you run only the ignored tests?

Answer 7

to ignore a specific test - add above its signature:
#[ignore]

to test all ignored tests, run:
cargo test – –ignored

Question 8

When will a test module code be compiled? will cargo build do it?

Answer 8

Cargo will only compile the test code under #[cfg(test)] when we run cargo test.
Cargo build won’t do it.

Question 9

Why there is no need to make internal_adder public for the test modules?

fn internal_adder(a: i32, b: i32) -> i32 {
    a + b
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn internal() {
        assert_eq!(4, internal_adder(2, 2));
    }
}

Answer 9

Because in Rust, because child module are able to access anything in their parent module, even private fields. 
(in the example code, tests module is the child)

Question 10

What is the convention of the location of unit tests in rust?

Answer 10

The convention is that unit test go in the same files as the code you’re testing.

*We use [cfg(test)] to specify that they shouldn’t be included in the compiled result

Question 11

Where does integration tests are written in Rust?

Answer 11

In Rust, integration tests are entirely external to your library.
We create a tests directory at the top level of our project directory, next to src. Cargo knows to look for integration test files in this directory.

Question 12

Do integration tests need the #[cfg(test)] annotation?

Answer 12

No, because of their known location. Cargo knows to look for integration test files in the “tests” directory.

Question 13

What does cargo do with the files in the tests directory?

Answer 13

Cargo will compile each of the files as an individual crate.

Question 14

The following code won’t compile. Why?

in tests/integration_test.rs:
use adder;
#[test]
fn it_adds_two() {
    assert_eq!(4, adder::add_two(2));
}

in sec/lib.rs:
fn add_two(a: i32) -> i32 {
a + 2
}

Answer 14

because add_two must be public. In tests directory we test only the public API, and can’t access private functions.

Question 15

How to run only integration tests?

Answer 15

cargo test –test –integration_test

Question 16

We want to add setup function before our integration step. This might be a useful step in multiple integration test files.
What is the convention to do it?

Answer 16

In test create a directory named “common”, and in it create a file named “mod.rs”.
In this file we can create a function:

pub fn setup() {
  // setup code specific to my library's tests...
}

In any of the integration test files we can use the setup in the following way:

mod common;

#[test]
fn some_test() {
  common::setup();
  // continue test logic here...
}