Add testing requirement to Contributing.md (GPUOpen-Drivers#1639)

Adding a section to Contributing.md to explicitly state the testing requirements that have been discussed informally in the past.

README.md

@@ -8,6 +8,8 @@
 
 * [Coding standard](docs/CodingStandards.md)
 
+* [Contributing guidelines](docs/Contributing.md)
+
 ## Third Party Software
 LLPC contains code written by third parties:
 * SPIRV-LLVM translator is distributed under the terms of University of Illinois/NCSA Open Source License. See llpc/translator/LICENSE.TXT.

docs/Contributing.md

@@ -128,6 +128,38 @@ useful as a comment when reading the code? Or does it only distract?
 Is the explanation independent of the current context and is it likely
 to stand the test of time?
 
+## Write useful tests
+
+New code requires new tests to be written that will exercise that code. This
+applies to bug fixes as well as new features. The tests serve two purposes:
+ensure that the new code does not regress if it needs to be changed and to give 
+an example of what the new code does.
+
+Test cases should be reduced as much as possible.  You can use 
+[Spir-V reduce](https://github.com/KhronosGroup/SPIRV-Tools#reducer) to help
+reduce the size of test cases, or do it manually.  This helps other developers 
+understand the tests better, and allows the tests to run faster.
+
+The tests must exist in the LLPC repository. They can be
+
+* a [shaderdb test](../llpc/test/shaderdb), 
+* an [LGC test](../lgc/test),
+* an [LLPC unit test](../llpc/unittests), or
+* an [LGC unit test](../lgc/unittests).
+
+We do not want to rely on the Vulkan CTS. Running the Vulkan CTS takes a long 
+time, putting a *time-to-test* burden on all developers. The Vulkan CTS tests
+are also harder to debug because more components are involved and require a GPU.
+
+To help developers know if their tests are covering their code change, a code
+coverage analysis will be run on all PR before they are submitted. The PR
+should only be merged if the new code is covered. Exceptions can be made if
+there is a good reason like the PR adds error handling code for an error that
+cannot be reproduced consistently. Note that this is just a minimum requirement
+and does not mean that the tests are effective.   If an existing test already
+covers the new code, that test should be updated to test for the new behaviour 
+or a new test should be added.
+
 ## Useful things to know about Git
 
 Not all projects that use Git aim for commits as the logical unit of change,