docs: move testing philosophy to docs folder

Signed-off-by: chjmil <[email protected]>

CONTRIBUTING.md

@@ -16,7 +16,7 @@ tests, integration tests, and security scans
 
 ## Pull Request Requirement
 All contributions (PRs) must be accompanied with passing unit and/or integration
-tests, following our [testing philosophy](./test/TestingPhilosophy.md). If you are unfamiliar with this process,
+tests, following our [testing philosophy](./docs/user/TestingPhilosophy.md). If you are unfamiliar with this process,
 we are happy to help through continuous collaboration within the pull request.
 All pull requests must also pass our linter analysis checks.  Contributiions may
 be subjected to security scans before acceptance.

test/TestingPhilosophy.md → docs/user/TestingPhilosophy.md

@@ -1,7 +1,7 @@
 # Testing Philosophy
 
 ## Introduction
-Our testing philosophy centers around ensuring the highest quality of infrastructure code through rigorous and systematic testing practices. We believe that thorough testing is essential to delivering a reliable and maintainable infrastructure solution.  In order to achieve this, we have set up a testing framework to run unit and integration tests. These tests are integrated into our CI/CD process. Because this project is community driven, we require both internal and external contributions to be accompanied by unit and/or integration tests as stated in our [CONTRIBUTING.md](../CONTRIBUTING.md) document. This ensures that new changes do not break existing functionality.
+Our testing philosophy centers around ensuring the highest quality of infrastructure code through rigorous and systematic testing practices. We believe that thorough testing is essential to delivering a reliable and maintainable infrastructure solution.  In order to achieve this, we have set up a testing framework to run unit and integration tests. These tests are integrated into our CI/CD process. Because this project is community driven, we require both internal and external contributions to be accompanied by unit and/or integration tests as stated in our [CONTRIBUTING.md](../../CONTRIBUTING.md) document. This ensures that new changes do not break existing functionality.
 
 ## Testing Approach
 
@@ -13,13 +13,13 @@ The unit tests are designed to quickly and efficiently verify the codebase witho
 
 ### Unit Testing Structure
 
-The unit tests are written as [Table-Driven tests](https://go.dev/wiki/TableDrivenTests) so they are easier to read, understand, and expand. The tests are be broken up into two files, [default_unit_test.go](./default_unit_test.go) and [non_default_unit_test.go](./non_default_test.go). 
+The unit tests are written as [Table-Driven tests](https://go.dev/wiki/TableDrivenTests) so they are easier to read, understand, and expand. The tests are be broken up into two files, [default_unit_test.go](../../test/default_unit_test.go) and [non_default_unit_test.go](../../test/non_default_test.go). 
 
 `default_unit_test.go` validates the default values of a terraform plan. This ensures that there are no regressions in the default behavior. `non_default_unit_test.go` modifies the input values before running the `terraform plan`. After generating the plan file, the test verifies that it contains the expected values. Both files are written as Table-Driven tests. Each resource type has an associated Test function.
 
 For example, look at the `TestPlanStorageDefaults` function in `default_unit_test.go` (copied below).
 
-With the Table-Driven approach, each entry in the `storageTests` map is a test. These tests verify that the expected value matches the actual value of the "module.nfs[0].azurerm_linux_virtual_machine.vm" resource.  We use the [k8s.io JsonPath](https://pkg.go.dev/k8s.io/[email protected]/util/jsonpath) library to parse the terraform output and extract the desired attribute.  The runTest call is a helper function that runs through each test in the map and perform assertions. See the [helpers.go](./helpers.go) for more information on the common helper functions.
+With the Table-Driven approach, each entry in the `storageTests` map is a test. These tests verify that the expected value matches the actual value of the "module.nfs[0].azurerm_linux_virtual_machine.vm" resource.  We use the [k8s.io JsonPath](https://pkg.go.dev/k8s.io/[email protected]/util/jsonpath) library to parse the terraform output and extract the desired attribute.  The runTest call is a helper function that runs through each test in the map and perform assertions. See the [helpers.go](../../test/helpers.go) for more information on the common helper functions.
 
 ```go
 // Function containing all unit tests for the Storage type
@@ -69,7 +69,7 @@ These test are still a work-in-progress. We will update these sections once we h
 
 ## How to run the tests locally
 
-Before changes can be merged, we require all unit tests to pass as part of our CI/CD process. Unit tests are automatically run against every PR using the [Dockerfile.terratest](../Dockerfile.terratest) Docker image. Please refer to [TerratestDockerUsage.md](../docs/user/TerratestDockerUsage.md) document for more information regarding locally running the tests.
+Before changes can be merged, we require all unit tests to pass as part of our CI/CD process. Unit tests are automatically run against every PR using the [Dockerfile.terratest](../../Dockerfile.terratest) Docker image. Please refer to [TerratestDockerUsage.md](./TerratestDockerUsage.md) document for more information regarding locally running the tests.
 
 
 ## Additional Documents