Test-Driven Development by Example, Using PowerShell — What is TDD?
Now you may be thinking, this all sounds great, but what exactly is TDD anyway?
Kent describes only two behaviors necessary for TDD.
1. Write new Code only if an automated test has failed.
2. Eliminate duplication.¹
These behaviors result in the following side effects.
- We must design organically, with running code providing feedback between decisions.¹
AKA, we make small changes toward our end goal, and the tests act as our navigation system.
- We must write our own tests, because we can’t wait 20 times per day for someone else to write a test.¹
In my previous article, I make a point of DevOps not getting the benefit of Manual QA. This being the case, you’re not likely to be getting any assistance writing automated test cases.
- Our development environment must provide rapid response to small changes.²
This point is actually the premise of this whole series. I thought to myself, scripting languages are more rapid than their sibling compiled languages. So what is stopping me from doing TDD?
- Our designs must consist of many highly cohesive, loosely coupled components, just to make testing easy.²
My main reason for writing unit tests historically has not been for the coverage, but this point. The inconvenience of writing testable dirty code is too great, so you are forced to write clean and loosely coupled code.
To simplify, Kent defines the “TDD Mantra” — Red/Green/Refactor.
- Red — Write a little test that doesn’t work, ̵a̵n̵d̵ ̵p̵e̵r̵h̵a̵p̵s̵ ̵d̵o̵e̵s̵n̵’̵t̵ ̵e̵v̵e̵n̵t̵ ̵c̵o̵m̵p̵i̵l̵e̵ ̵a̵t̵ ̵f̵i̵r̵s̵t̵.̵
- Green — Make the test work quickly, committing whatever sins necessary in the process.
- Refactor — Eliminate all of the duplication created in merely getting the test to work.²
The only obvious modification here for Powershell is the lack of compiling. Aside from this, we are 100% capable of doing TDD with Powershell, No Excuses!
So to put that another way. You take one of your requirements and make it into a test (Red). You then get to implement the requirement (Green). Then before you repeat the process, you take a moment to clean off your work surface (Refactor).
It’s that simple, and it’s a beautiful thing.
I hope you’ve enjoyed my explanation of What TDD Is.
- To go on and read my next post (3 min): Test-Driven Development by Example, Using PowerShell — Setting up your local environment.
- If you haven’t read my opening post of the series, check it out (2 min): Test-Driven Development by Example, Using PowerShell
- Or to read my previous post on WHY you should be using TDD with DevOps (3 min): Test-Driven Development by Example, Using PowerShell — Preface & Introduction — Why you should be using TDD with your DevOps practice?
- Kent Beck, Test-Driven Development By Example (Boston, MA: Pearson Education, Inc, 2003), ix
- Beck, Test-Driven Development, x