Improve documentation of the integration tests

Also:
* disable rustfmt in the integration test, to avoid it causing problems, since
  it is not needed.
* note the need to rebuild bindgen when running a single test.

2 files changed, 25 insertions, 3 deletions

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 0a06709a..1fb9ca8c 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -19,6 +19,7 @@ out to us in a GitHub issue, or stop by
   - [Testing a Single Header's Bindings Generation and Compiling its Bindings](#testing-a-single-headers-bindings-generation-and-compiling-its-bindings)
   - [Authoring New Tests](#authoring-new-tests)
   - [Test Expectations and `libclang` Versions](#test-expectations-and-libclang-versions)
+  - [Integration Tests](#integration-tests)
   - [Fuzzing `bindgen` with `csmith`](#fuzzing-bindgen-with-csmith)
 - [Code Overview](#code-overview)
 - [Pull Requests and Code Reviews](#pull-requests-and-code-reviews)
@@ -88,9 +89,9 @@ output Rust bindings live in `tests/expectations/tests`. For example,
 `tests/headers/my_header.h`'s expected generated Rust bindings would be
 `tests/expectations/tests/my_header.rs`.
 
-There is also the `./bindgen-integration` crate, which uses `bindgen` to
+There are also some integration tests in the `./bindgen-integration` crate, which uses `bindgen` to
 generate bindings to some C++ code, and then uses the bindings, asserting that
-values are what we expect them to be both on the Rust and C++ side.
+values are what we expect them to be, both on the Rust and C++ side.
 
 The generated and expected bindings are run through `rustfmt` before they are
 compared. Make sure you have `rustfmt` up to date:
@@ -100,6 +101,10 @@ $ rustup update nightly
 $ rustup run nightly cargo install -f rustfmt-nightly
 ```
 
+Note: running `cargo test` from the root directory of `bindgen`'s repository does not
+automatically test the generated bindings or run the integration tests.
+These steps must be performed manually when needed.
+
 ### Testing Bindings Generation
 
 To regenerate bindings from the corpus of test headers in `tests/headers` and
@@ -117,7 +122,7 @@ should be sufficient to test your local modifications.
 If your local changes are introducing expected modifications in the
 `tests/expectations/tests/*` bindings files, then you should test that the
 generated bindings files still compile, and that their struct layout tests still
-pass.
+pass. Also, run the integration tests (see below).
 
 You can do this with these commands:
 
@@ -138,6 +143,9 @@ searching for test headers. For example, to test
 $ ./tests/test-one.sh going
 ```
 
+Note that `test-one.sh` does not recompile `bindgen`, so if you change the code,
+you'll need to rebuild it before running the script again.
+
 ### Authoring New Tests
 
 To add a new test header to the suite, simply put it in the `tests/headers`
@@ -195,6 +203,19 @@ Where `$VERSION` is one of:
 
 depending on which version of `libclang` you have installed.
 
+### Integration Tests
+
+The `./bindgen-integration` crate uses `bindgen` to
+generate bindings to some C++ code, and then uses the bindings, asserting that
+values are what we expect them to be, both on the Rust and C++ side.
+
+To run the integration tests, issue the following:
+
+```
+$ cd bindgen-integration
+$ cargo test
+```
+
 ### Fuzzing `bindgen` with `csmith`
 
 We <3 finding hidden bugs and the people who help us find them! One way to help
diff --git a/bindgen-integration/build.rs b/bindgen-integration/build.rs
index 54546ab0..071d72b5 100644
--- a/bindgen-integration/build.rs
+++ b/bindgen-integration/build.rs
@@ -28,6 +28,7 @@ fn main() {
     let macros = Arc::new(RwLock::new(HashSet::new()));
 
     let bindings = Builder::default()
+        .rustfmt_bindings(false)
         .enable_cxx_namespaces()
         .rustified_enum(".*")
         .raw_line("pub use self::root::*;")