The Pester Book with @adbertram

Adam Bertram has graciously agreed to collaborate with me on The Pester Book, a book we’ll be Agile-publishing on LeanPub, as I’ve done with The DSC Book. A highlight of LeanPub, for me, is that we can publish an initial batch of chapters, and then keep adding to the book over time – and even revising it as Pester itself evolves – and ensure that every buyer gets an updated copy of the book at no additional charge. It’s like a lifetime subscription! We’re currently thinking of a $10-$15 cover price, although over time as the book grows that may bump up for new purchases.

Anyway, I have a question first.

If you’ve used Pester, or even read about it, what are some of the things that have confused you, or gotten you stuck? The more specific you can be, the more able we’ll be to make sure our book addresses it – which will help everyone, in the long run. Drop your comments below!

Now, for a bit on our strategy with the book. Our initial release will cover the basic concepts, syntax, and pre-requisite design concerns (e.g., your code has to be designed to be testable). We’ll hit everything in the official docs, but offer context and explanations and practices to those.

Phase two will include integrating some of what we (especially Adam) has already written elsewhere – not copying and pasting his excellent articles, but integrating their concepts into the text.

Phase three will expand the book to focus on a series of real-world, from-scratch examples: building tests from scratch for existing code, building infrastructure validation tests (Adam’s specialty), and starting with a test-driven design approach.

As we go, we’ll incorporate reader feedback, and over time we’ll continue to expand, add more examples, and cover more situations and practices based on what folks tell us they’d like to see added. We’re looking forward to working on the book! It may be a month or so before we get the initial release ready to go, but I’m hoping in the meantime to collect some good responses to the question above.


  1. Hey guys, great idea, can’t wait for the release! I’m sure that this will be covered but how do you identify what doesn’t need to be tested? I find when I sit down to write tests the hardest part for me thus far has been knowing what to focus on and what not to.

  2. Pingback: Everything You Ever Wanted to Know about Pester - Adam, the Automator

  3. I really like the sound of this. I’ve only superficially investigated Pester, but have read a lot and have further interest in it. The one area that seems, like Pester or related to Pester is OVF (Operational Validation Framework). Which seems to be Pester for systems rather than Pester for code. The idea of writing tests that validate, deployments or systems changes to me seem more practical and universally valuable to my teams at large then writing tests for my modules.

  4. Awesome looking forward to this very much.
    Things that caught me out when I started

    – testing for errors using throw
    – error “The script failed due to call depth overflow.”

    both of which I wrote a little blog about as they are relatively simple if not intuitive to resolve but ought to be included IMHO

    I generally am getting stuck around mocking as I am largely in the SQL space and use SMO and a lot of the code in the dbatools module is using the methods and properties of the SMO-Object but also collections of objects within the main object – Adam can explain more as I am in contact with him about that

    Confusing – Mocking is generally something I have struggled to understand – where to put the Mock? Inmodulescope etc

    What should I be testing? for TDD

    I think a lot of people who want to use Pester in this way because we have been to events or watched videos saying that we should and it looks cool and exciting and a good thing to learn, come from a sys admin/infrastructure background rather than a development background so that level of understanding is missing

    There is probably more things which if I remember I will pass on. Want me to expand/explain – give me a shout

    Also – could you create a time machine when you have finished and transport the book back to me at the end of 2015 Thanks 🙂

  5. Two things. First, I agree with Joel that operational validation (OVF, PoshSpec) is beginning to be really visible and would be nice to cover.

    The second is “how much do I mock?” I write a lot of tools for database access and I’m always wondering about how to test without having a real SQL Instance to talk to. If I mock SQL, I’m not sure that I’m testing my tool as much as I’m testing my ability to write a mock object. On the other hand, it’s hard to write a reproducible test and include all of the SQL setup required to make it work.

  6. Pingback: Up Next: Don Jones & Adam Bertram on The Pester Book!

  7. Pingback: Episode 319 - PowerScripting Podcast - MVPs Don Jones and Adam Bertram on Pester

What do you think?

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s