![]() This gets old fast and gets even worse when you have to revisit it a few days or weeks later. ![]() We catch ourselves rerunning cleanup, rerunning the setup, then rerunning our code and then checking the same conditions. Sounds reasonable until the manual validations prove the code is broken again and again and again. The first time we run through our code changes, we think we'll manually run it, validate it and then move on. Until the script works, testing it is a pain Once the script works, why would it break? In the case of provisioning infrastructure, many may feel if the VM comes up and runs its bootstrap installs without errors, extra validations are a luxury. One may argue: Why quibble over these implementation details? We are taking a huge, slow manual process that took an army of operators hours to accomplish and boiling it down to an automated script that does the same in a few minutes. Sometimes it is a conscous inability to see value in adding tests but many times the developers just are not considering tests or have never written test code. I've encountered these sentiments both in infrastructure and more traditional coding circles. By the time your tests turn green, I've shipped already and am in the black. There's your test!ĭon't dump your friction laden values on my devops rainbow. I'll also touch on TDD which I am passionate about but less dogmatic on the subject than I once was. I'm intentionally surrounding scripts in quotes because I'm finding that one person's script quickly become a full blown application. So this post is a collection of observations and thoughts on testing "scripts". However, I'm fairly competent in writing tests and believe the discovery of TDD was a turning point in my becoming a better developer. I believe god placed cidr calculators on the internet (thanks god!) for calculating IP ranges and wikipedia for a place to lookup the OSI model. I'm part of the "dev" group and have no right to judge here. So you have talented devs that don't know layer 1 from layer 2 networking and think CIDR is just something you drink and experienced admins who consider share point a source control repository and have never considered writing tests for their automation. In some windows circles, we see more administrators learning and writing code who have never scripted before. As "infrastructure as code" is growing in popularity we have devs writing more systems code and admins/ops writing more and more sophisticated scripts. Why use pester (or any unit testing framework) at all? Really? Unit tests for a "scripting" language? I have not been writing much powershell at all these days but these questions are just as applicable to infrastructure code written in ruby I have been writing. I have alot of thoughts on this subject but I'd like to expand the question to an even broader scope. I have written a couple posts on HOW to use pester and I'm sure I mentioned TDD but I really don't recall ever seeing any posts on WHY one would use TDD. I was asked a couple weeks ago by Adam Bertram twitter for any info on why one would want to use TDD with Pester.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |