sdoubleday

#Run this on new Microsoft Development VMs.
#Powershell run as administrator

#region PowerShell and Package Managers
#Set Execution Policy
Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned -Force;

Write-Verbose -Verbose 'Start with package managers...';
Write-Verbose -Verbose 'Chocolatey...';
#Get Chocolatey

sdoubleday

Unit Testing Articles

General Unit Testing Principles

• A "Hello World" description of how and why to unit test: http://geepawhill.org/how-to-test-depends-on-what-to-test-money-chaining-and-steering/
  • My very favorite unit testing mantra comes from that article:

The money premise reminds us this is more value faster. The chain premise tells us to test parts rather than the whole. The steering premise tells us to change our code to make that possible. --Mike "Geepaw" Hill

• How to split a complicated task into simple tasks for unit testing:: https://www.geepawhill.org/2019/08/12/story-splitting-3-easy-customer-first/

sdoubleday

#Classes do not always play well in the nested modules section of a manifest. I've had trouble with importing classes in multiple files.
#My current approach is: Create a .ps1 file WITHOUT the standard clauses of BEGIN{} PROCESS{} END{} that uses invoke-expressions:

$invocables = @()

$invocables += $( get-content "$PSScriptRoot\MyFolder\MyClass.psm1" ) -join "`r`n"
$invocables += $( get-content "$PSScriptRoot\MyOtherClassThatDepenedsOnTheFirstOne.psm1" ) -join "`r`n"

foreach ($i in $invocables) { Invoke-Expression -Command $i }

sdoubleday

<#
Why? I don't know why. But mechanically, when you import a manifest, the paths to scripts to process are checked first in the 
present working directory $PWD, and THEN in the manifest's parent folder. Thus, if you have the same named script in both your PWD
and in the module folder, when you load the module it will run the script in your PWD, NOT the one in the module.

Thankfully, instead of doing this in your manifest:

ScriptsToProcess = @(".\myScript.ps1")

you can this:

sdoubleday

<#
If you create enums and/or custom attributes and want to reuse them, you would (or at least, I did) think that they should go into psm1 module files and be included in other modules via the NestedModules line of the module manifest.
BUT YOU WOULD BE (or at least, I was) WRONG!
Instead, create them in .ps1 script files and add them to the ScriptsToProcess line of the module manifest.
And if you use the enum directly in Pester tests, you will need to run the enum script file there, too, as they do not persist between scripts (as noted here: https://tfl09.blogspot.com/2014/11/enums-in-powershell-v5.html).

That said, if you follow this advice for enums (is it that the enums are in ScriptsToProcess, or anything? I haven't tested), you may need to refactor classes into THEIR own psm1 files. But in so doing, you may break Get-Help and intellisense for functions that take objects of those classes as parameters. At which point you may wind up with all the Enums and Classes back in the main psm1 file(s).

By way of

sdoubleday

#Simple functions and aliases that don't rise to the level of a module that I like having in my PowerShell Profile

function sudo {[CmdletBinding(<#PositionalBinding=$True#>)]PARAM([String]$CommandLine,[Switch]$RunPrior) IF($RunPrior.IsPresent) {$CommandLine = (Get-History | Select-Object -Last 1).CommandLine}; Write-Verbose "Running: $CommandLine"; start-process powershell -verb:Runas "$CommandLine"}

function outlook {. 'C:\Program Files (x86)\Microsoft Office\root\Office16\OUTLOOK.EXE' /restore}

function newdir {PARAM($Path)  new-item -ItemType Directory -Path $Path }

function ssms2008 {ls 'C:\Program Files\', 'C:\Program Files (x86)\' -Filter micro*Sql*server | ls -Filter '100' | ls -Recurse -Filter *ssms*exe | ii}

sdoubleday

<#
A brief example to answer the question:
In Powershell, why does my child constructor fail when I have logic in my base class default constructor?
Or more plaintively:
  powershell why doesn't my child constructor work
  powershell why doesn't my child constructor fire
  powershell why doesn't my child constructor override base class constructors

I tested this in version: 5.1.14393.1532 

sdoubleday

sp_executesql @stmt = N'SELECT '',['' + Table_name + ''].['' + Column_Name + '']'' AS QualifiedColumnName , * FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME LIKE @input', @params = N'@input varchar(1000)', @input =

SELECT * FROM 

sp_HelpText 

SELECT TOP 60 * FROM 

sp_BlitzFirst @expertmode = 1, @seconds = 5

sdoubleday

<#When populating Azure data stores, sometimes I find it is simplest to copy a great deal of data over the network, but I do not have authorization to monopolize the outbound pipe. In those cases, I copy data with AzCopy.exe on one server, and I throttle those copy jobs by setting up a Quality of Service policy on that server. This solution relies on running all copy jobs through the server that has this policy enabled. It should throttle multiple parallel copy jobs to the TOTAL ThrottleRateActionBitsPerSecond you specify. ActiveStore means this does NOT persit after reboots. Pick a rate that is appropriate to your environment.

Remember that when setting up QOS policies, you need to throttle the thing DOING the copying, not the thing INVOKING the thing doing the copying. I.e., if you run your azcopy.exe job in PowerShell, don't throttle PowerShell, throttle azcopy.exe#>

New-NetQosPolicy -Name throttleAzCopy -PolicyStore ActiveStore -AppPathNameMatchCondition azcopy.exe -ThrottleRateActionBitsPerSecond 25MB

sdoubleday

Notes on the act of developing with external repositories (i.e. submodules) in git and pester

*To the reader:* If you are here looking for expert advice, please leave as swiftly as possible. No such advice is present here. This is purely a set of reminders for the physical(?) act of how I handle working with git submodules and pester tests.

This assumes you are working in PowerShell. Version 5, if it matters, with git 2.10 (or later? It was what I had when I wrote this) and pester.

*Downloading and using a repo with submodules* - When I was getting started with this, I NEVER developed submodules from the main module. I schlepped over to the submodule, branch, develop, merge back to master, and then come back here and update the submodule, and I still think that's a good policy for anything other than mass hotfixes.

Clone the repo as normal. Here, the folder PesterNewFixtureModule will be created in the current folder:
	git clone https://github.com/sdoubleday/PesterNewFixtureModule.git PesterNewFixtureModu