Organizing tests

At a minimum, there are two kinds of tests that we usually write when developing software: unit tests and integration tests. They both serve different purposes and interact differently with the code base under test. Unit tests are always meant to be lightweight, testing individual components so that the developer can run them often, thus providing a shorter feedback loop, while integration tests are heavy and are meant to simulate real-world scenarios, making assertions based on their environment and specification. Rust's built-in testing framework provides us with sane defaults for writing and organizing these tests:

• Unit tests: Unit tests are usually written within the same module that contains the code to be tested. When these tests increase in number, they are organized into one entity as a nested module. One usually creates a child module within the current module, names it tests (by convention) with an annotation of the  #[cfg(test)] attribute over it, and puts all the test-related functions inside of it. This attribute simply tells the compiler to include code within the tests module, but only when cargo test is run. More on attributes in a moment.
  
• Integration tests: Integration tests are written separately in a tests/ directory at the crate root. They are written as if the tests are the consumer of the crate being tested. Any .rs file within the tests/ directory can add a use declaration to bring in any public API that needs to be tested.

To write any of the aforementioned tests, there are some testing primitives we need to be familiar with.