I wrote a post about Help Driven Development (HDD) some time back. To summarize, HDD builds on top of what I have since come to understand as Behavioral Driven Development (BDD) and Test Drive Development (TDD). The aim of the paradigms are to improve code and invert the normal process, prioritizing the tasks that often get cast aside in haste, using testing frameworks and writing help.
With HDD, we first write our help and use this as a guide to write our tests. Finally, we use our tests to write our code. That code is written to pass the tests. It might seem to have parallels with “teaching to the test,” but the process helps to create simple, quality code.
For reasons, I am refactoring my Exchange Web Services module. It was originally called xExchange.WebServices, but starting now, it will be dxExchange.WebServices, as I will be prefixing my modules with “dx”. First, it isn’t far off from the “x,” I am just prepending a “d”. However, I think it will help to better brand modules as my own and it rings of derivatives, which I like. It probably goes without saying, however, that the “d” is from my name.
More Than Just HDD
This is not just an effort to implement HDD, BDD, or TDD, but it is also an effort to add some more completeness to the module. I originally wrote this module to help me with a specific task. I had worked with Exchange Web Services (EWS) on a couple of occasions for some one-off work (i.e. Importing Exchange UM greetings from WAV files, and testing connectivity to EWS for someone whose application stopped working). Each time, I had to work through the nuances of just getting connected. When the third opportunity presented itself to work with EWS, I decided to write a few functions to help me avoid the pains of the past and the xExchange.WebServices module was created.
I have since started doing some other work with the module. The basic components of the module do allow you do to do pretty much anything with EWS as you can just continue to manually implement the aspects of the API that have not yet been written into the module. However, I learned a bit more about the API and started some enhancements. Further, I wanted the API to be more usable for others which means at least having some help implemented would be useful.
Further, I am starting to mature my development within PowerShell further and have started looking into CI/CD and how to add this into my skillset. I began thinking about how one could implement these concepts into a language that does not have a compilation component and discussed it with a few people in the PowerShell community. This has led me to breaking out my PSM1 file into separate PS1 files for each function that get dot-sourced into the PSM1. This also helps to break apart the Pester tests into separate .Tests.PS1 files.
Combined, this code refactoring should help to develop a more refined module that is also more complete and usable.
The Pester Book
As a side note, I would like to direct anyone interested to The Pester Book, by Adam Bertram. Adam is an MVP for his investments into the PowerShell community and this book is a great source of information related to Pester. Plus, he is a fellow Hoosier. It is available on LeanPub in an evergreen format, so updates will continue to be published and are immediately available to you.
Dustin Dortch 