Integration testing

Unit tests are testing one module in isolation at a time: they’re small
and can test private code. Integration tests are external to your crate and use
only its public interface in the same way any other code would. Their purpose is
to test that many parts of your library work correctly together.

Cargo looks for integration tests in tests directory next to src.

File src/lib.rs:

  1. // Assume that crate is called adder, will have to extern it in integration test.
  2. pub fn add(a: i32, b: i32) -> i32 {
  3. a + b
  4. }

File with test: tests/integration_test.rs:

  1. // extern crate we're testing, same as any other code would do.
  2. extern crate adder;
  3. #[test]
  4. fn test_add() {
  5. assert_eq!(adder::add(3, 2), 5);
  6. }

Running tests with cargo test command:

  1. $ cargo test
  2. running 0 tests
  3. test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
  4. Running target/debug/deps/integration_test-bcd60824f5fbfe19
  5. running 1 test
  6. test test_add ... ok
  7. test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
  8. Doc-tests adder
  9. running 0 tests
  10. test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

Each Rust source file in tests directory is compiled as a separate crate. One
way of sharing some code between integration tests is making module with public
functions, importing and using it within tests.

File tests/common.rs:

  1. pub fn setup() {
  2. // some setup code, like creating required files/directories, starting
  3. // servers, etc.
  4. }

File with test: tests/integration_test.rs

  1. // extern crate we're testing, same as any other code will do.
  2. extern crate adder;
  3. // importing common module.
  4. mod common;
  5. #[test]
  6. fn test_add() {
  7. // using common code.
  8. common::setup();
  9. assert_eq!(adder::add(3, 2), 5);
  10. }

Modules with common code follow the ordinary modules rules, so it’s ok to
create common module as tests/common/mod.rs.