From 7675de8d74810b28d3ae7cafdfd8174df9a310d6 Mon Sep 17 00:00:00 2001 From: Andrew Schwartzmeyer Date: Wed, 18 May 2016 10:08:05 -0700 Subject: [PATCH] Link Pester readme to Pester Do and Don't --- test/powershell/README.md | 99 ++------------------------------------- 1 file changed, 3 insertions(+), 96 deletions(-) diff --git a/test/powershell/README.md b/test/powershell/README.md index 21ba2f1c9..ec93e0f52 100644 --- a/test/powershell/README.md +++ b/test/powershell/README.md @@ -1,6 +1,9 @@ Pester Testing Test Guide ========================= +Also see the [Pester Do and Don't](../../docs/testing/PesterDoAndDont.md) +document. + Running Pester Tests -------------------- @@ -47,99 +50,3 @@ Pending When writing a test that should pass, but does not, please do not skip or delete the test, but use `It "Should Pass" -Pending` to mark the test as pending, and file an issue on GitHub. - -Who this is for ---------------- - -Cmdlet behavior is validated using the Pester testing framework. The -purpose of this document is to create a single standard to maximize -unit test coverage while minimizing confusion on expectations. What -follows is a working document intended to guide those writing Pester -unit tests for PowerShell. - -Unit testing is done not only to validate that the block of code works -as expected, but also to assist the developer to know precisely where -in the code to look; in some cases, seeing the source code may inspire -better unit tests. In many cases, a unit test *is* the only documented -specification. Fortunately, the MSDN is a great source of information -about Cmdlets. - -Test suites need to be created and many cmdlets added and unit-tested. -The following list is to be used to guide the thought process of the -developer in writing a suite in minimal time, while enhancing quality. - -Test suites should proceed as functional and system tests of the -cmdlets, and the code treated as a black box for the purpose of test -suite design. - -Testing Standards ------------------ - -### Readability - -Every effort should be made to maximize readability of code. Code is -written for the developer in the future to debug- not for the -developer writing the code. - -1) When assertions are on consecutive lines, the pipes should line up: - -```sh -MyFirstCondition | Should Be 0 -MySecondCondition | Should Be 1 -``` - -This is less readable than: - -```sh -MyFirstCondition | Should Be 0 -MySecondCondition | Should Be 1 -``` - -So the second section of code should instead be used. The same style -should be followed for assignments of variables on consecutive lines: - -```sh -$var1 = -$variable2 = -$var3 = -$typeCollection1 = -$object1 = -... etc -``` - -is much less readable than - -```sh -$var1 = -$variable2 = -$var3 = -$typeCollection1 = -$object1 = -... etc -``` - -So all assignment statements must be aligned. - -Other style standards are no less important to readability of the code: - -- Use readable and meaningful variable name when assigning variables. - -- Do not make large functions. Tests should be simple: define -> - manipulate -> assert - -- Do not use tabs. Tabs are rendered differently depending upon the - machine. This greatly affects readability. - -- Remove the first 3 auto-generated lines of each .Tests.ps1 file. - This is created automatically by Pester and is unnecessary. Each - .Test.ps1 file should begin with a Describe block. - -- Discard the auto-generated function file that is generated in tandem - with the .Tests.ps1 file - -- Name the test file "Test- when you create a new test - fixture. - -- Each test describes a behavior- use the word "Should" at the - beginning of each test description- so it reads "It 'Should..." -