I’ve created a template to quickly get started building a sample PowerShell Module that includes different components such as Classes, Enum, private and public functions, DSC Resources, some Unit tests, Quality tests, code coverage, deployment, dependency resolution for build, and AppVeyor Integration.
Technical
I’ve for long thought Interface Testing was the most repetitive yet critical task to let a Module or commands evolve without breaking backward compatibility, and upsetting those who depends on it.
While Unit Testing ensures the code behaves as expected and meets its design and requirements, Interface Testing for commands or functions focuses on the contracts it offers to its consumer. It ensures the contracts (the command prototype or syntax) are consistent over time.
This is the second article in a “getting started with DSC Development”, covering tools and workflow. The previous post was covering general Windows Automation techniques, some of them existing since the Windows XP days and before!
This time we’ll look at tools, techniques and workflow that will enable us to make changes using scientific method, iteratively.
This is the first article in a series that aim to explore one way of getting started with DSC Development, covering tools and workflow.
In very short and abstract, the life cycle of a Windows Server could look like:
- Deployment (aka OSD)
- Configuration
- Maintenance
- Decommission
This series aims to focus at the Configuration part, mainly in its development phase, but also covers the basics of creating windows Image for experimentation purposes. The idea is to get started experimenting quickly, but I would not use this approach of Image creation for something that needs to be maintained.
This is a work through of some exploration I implemented in PowerObject and MethodHelpers, the gist shows an example of the latter.
