finsihed ch11

Test_Organization.md

@@ -165,3 +165,136 @@ There are three sections of the output
 Note that if any test in a section fails the following sections will not run
 For example if a unit test fails, there wont be any output for integration and doc tests because those tests will only be run if all unit tests are passing.
 
+The integration tests scetion starts after the unit tests (one per line) and the unit summary test section.
+
+It beings with th line `Running tests/integration_test.rs`
+
+Next there is a line for each test function in that integration tests and a summary line of the integration test just before the `Doc-tests adder` section starts
+
+Each integration test file has its own section, so if more files in the *test* directory, there will be more integration test sections.
+
+We can run a particular integration test function by specifying the test function's name as an argument to `cargo test`
+
+To run all the tests in a particular integraion file use the `--test` argument of the `cargo test` followed by the name of the file
+
+Here is an example of running a particular file
+```
+$ cargo test --test integration_test
+   Compiling adder v0.1.0 (file:///projects/adder)
+    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.64s
+     Running tests/integration_test.rs (target/debug/deps/integration_test-82e7799c1bc62298)
+
+running 1 test
+test it_adds_two ... ok
+
+test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
+```
+### Submodules in Integration Tests
+As you add more integartion tests, you might want to make more files in the *tests* directory to help organize them
+
+For example you might want to group the test functions by the functionality that they are testing
+
+As mentioned previously each file in the test dir is compiled as its own separate crate which is useful for creating separate scopes to more closely imitate the way end users will be using your crate.
+
+This means files in the *tests* directory don't share the same behavior as files in the *src* do
+
+A refesher on speerate code modules can be found [here](./Modules%20and%20Use.md)
+
+The different behavior of *tests* directroy files is most present when you have a set of helper fnctions to use in multople integration test files.
+
+For this you can follow the steps in the ["Separating Modules in Different Files"](./Modules%20and%20Use.md) to extract them into a common module.
+
+For example if we create a file in *tests/common.rs* and place a function named `setup` in it.
+
+We could add some code to `setup` that we want to call from multiple test function in multiple test files
+```rust
+pub fn setup() {
+    // setup code specific to your library's tests would go here
+}
+```
+When we run `cargo test` we see a new section for the output for the common.rs file even though this tet doent contain any test functions nor did we call the `setup` function from anywhere
+
+Here is the output
+```
+$ cargo test
+   Compiling adder v0.1.0 (file:///projects/adder)
+    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.89s
+     Running unittests src/lib.rs (target/debug/deps/adder-92948b65e88960b4)
+
+running 1 test
+test tests::internal ... ok
+
+test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
+
+     Running tests/common.rs (target/debug/deps/common-92948b65e88960b4)
+
+running 0 tests
+
+test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
+
+     Running tests/integration_test.rs (target/debug/deps/integration_test-92948b65e88960b4)
+
+running 1 test
+test it_adds_two ... ok
+
+test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
+
+   Doc-tests adder
+
+running 0 tests
+
+test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
+```
+Having `common` appear in the test results with `running 0 tests` displayed for it is not what we intended.
+
+We just want to share some code with the other integration test files.
+
+To avoid having `common` appear in the test outputs you would create a file in *tests/common/mod.rs* instead of *tests/common.rs*
+
+Here is how the project directory should look like
+```
+├── Cargo.lock
+├── Cargo.toml
+├── src
+│   └── lib.rs
+└── tests
+    ├── common
+    │   └── mod.rs
+    └── integration_test.rs
+```
+This is the older naming convention that Rst also understands for adding different modules.
+
+Naming the file this way tells Rust to not treat the `common` module as an integration test file
+
+When we move the `setup` function code into *mod.rs* and delete the *common.rs*  file the section in the test output will no longer appear.
+
+file in subdirectories of the *tests* directory don't get compiled as separate crates or have sections in the test output.
+
+We can use the *mod.rs* file from any integration test file as a module
+
+Here is an example of calling the `setup` function form the `it_adds_two` test in *tests/integration_test.rs*
+```rust
+use adder::add_two;
+
+mod common;
+
+#[test]
+fn it_adds_two() {
+    common::setup();
+
+    let result = add_two(2);
+    assert_eq!(result, 4);
+}
+```
+### Integration Test for Binary Crates
+If your project is a binary crate that only contains a *src/main.rs* file and doesn't have a *src/lib.rs* file we can't create integration tests in the *tests* directory and bring functions defined in that *main.r* file into scope with a `use` statement.
+
+Only library crates expose functions that other crates can use.
+
+Binary crates are meant to run on thier own.
+
+This is why Rust projects have a very simple *main.rs* file that calls upon logic that lives in the library crate
+
+Using that structure integration tests *can* test the library crate using `use` to make the important functionality available.
+
+If the important funtionality works the small amount of code in *src/main.rs* file will work as well and that small amount of code doesn't need to be tested.

Tests.md

@@ -34,3 +34,5 @@ This chapter will cover:
 - [Test Organization](Test_Organization.md)
 
 But it will also talk about Rust's testing facilities, the annotations and macros available to you when writing tests, the default behavior and options provided for running your tests and how to organize tests into unit tests and integration tests.
+
+Test are still important to check that the functionality, logic or expectations to behave work even with all of Rusts checks (type system and ownership rules) to prevnt bugs.