tawasuyu/taffy

* Add test guideline

* Space around lists

* Fix idents and numbering

* Remove double wrapped integration-test example

* Add note of paramter-based testing

* Apply suggestions from code review

Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>

Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 6f2b9c57f..62235a37c 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -16,6 +16,8 @@ If you'd like to help on a consistent basis or are interested in project managem
 
 ## Testing
 
+### Running tests
+
 Flexbox layouts are tested by validating that layouts written in this crate perform the same as in Chrome.
 This is done by rendering an equivalent layout in HTML and then generating a Rust test case which asserts that the resulting layout is the same when run through our layout engine.
 
@@ -30,6 +32,50 @@ Once you have chromedriver installed and available in `PATH` you can re-generate
 
 To add a new test case add another HTML file to `/test_fixtures` following the current tests as a template for new tests.
 
+### Writing tests
+
+1. All tests should be wrapped in a module called `tests` gated by the standard `test` feature flag, to ensure they are not compiled unless tests are being run.
+
+    ```rs
+    #[cfg(test)]
+    mod tests {
+        // Place tests here
+    }
+    ```
+
+2. For unit-testing this should be placed in the same file as the code they are testing
+    1. If files become extremely long (more than a couple thousand lines of code), tests should be split out into its own file under the same module
+
+    ```rs
+    // file: ./src/my_struct.rs
+    struct MyStruct;
+
+    impl MyStruct {
+        fn some_method() { .. }
+    }
+
+    #[cfg(test)]
+    mod tests {
+        #[test]
+        fn test_of_some_method() { .. }
+    }
+    ```
+
+3. For integration tests this should be placed within the `./tests` folder
+
+    ```rs
+    // file: ./tests/my_integration_test.rs
+    #[test]
+    fn integration_test_one() { .. }
+    #[test]
+    fn integration_test_two() { .. }
+    ```
+
+4. Each test should have a clear intent
+    1. It should be evident what is being tested (naming, code, comments)
+    2. When this test fails, it should be easy to understand what went wrong
+    3. Fixture-based tests (`#[rstest]`) can help improve clarity when many related scenarios need to be checked
+
 ## Benchmarking
 
 Benchmarks build on the same infrastructure as testing, and actually benchmarks are automatically generated from test fixtures just like tests.