Hi. After reading Adam’s intro to the Pester book I thought I’d check if you’ve also experienced and overcome the main pester problem I have right now. Basically, I don’t always plan my code properly which is definitely not conducive to TDD.
So for example, I have to write a small script/module. I dive right in thinking I need Functions A and B. Function A then starts to become too large so I split it into two (Functions A and C). Start on Function B, realise it actually has to do two things so create Function D. Then realise if I refactor C I can make it the overall script more usable and not need B at all.
So I start thinking I need two functions, A and B, and it ends up evolving into A2, C and D. If I do TDD I end up writing useless tests and having to write the tests afterwards anyway (which often seems like I’m writing tests just to pass).
Having gone through your mind switch, do you think its just the case of “doing it” and with practice it gets easier to correctly plan the code and write valid pester tests?
First of all, I don’t do traditional TDD. I’ve found it to be putting the cart before the horse. The way I write code is how you outline. When I start, I have no idea how I want to solve it. The only way I can figure that out is by actually doing it. Traditional TDD says write a test first, see it fail, refactor and see it pass.
I write the code required and “eyeball test” it which basically means running it to ensure it didn’t throw any errors and manually checking or just spot checking whatever it was supposed to change. This is where I would have left off before writing tests. I now take the extra step and write tests for that code. I usually create a bunch of It blocks to just lay out what I want to test. I then fill in all the mocks necessary and go from there.
As I go, I then try to create a passing test. If it passes then I think I’ve got the right test. To confirm though, I’ll change something simple to make it fail. If it fails, I know I have a good test. It’s sorta like TDD after the code is written.
The biggest change for me was feeling like it just wasn’t worth it. While writing tests, I used to constantly ask myself “This is taking forever. Is this really worth all this extra time?”. It wasn’t until I start catching bugs as I was going through the process that I wrote and catching regression bugs my team wrote that we really saw the benefit of testing. Also, the trust factor was HUGE. With no tests, you never really trust the code. When writing a great test suite, you have the confidence that if a problem crops up you’ll find it early.
Ok thanks Adam. Its good to know that you still work that way and also that writing tests afterwards is not necessarily “wrong” and more important to write a great test suite.
I do it similarly. TDD is a great concept, but it’s not a replacement for thinking process, or understanding of the problem. I often start with a problem, write a big high level test to figure out what I actually want to do.
Then I make make a quick prototype to fulfill the requirements of that big test. At that moment I know what I want to do, so I do it properly with test first.
Writing nice code first and applying tests on it later, the way Adam describes (characterization tests), also happens sometimes, but it tends to be more work than doing it the other way. If it is not, then I find that un-interesting code (like null checks) often get’s skipped.
It also depends a lot on the type of code you write. I tend to write a lot of code that can be unit tested, which is a bit simpler to TDD than infrastructure.
I also often use tests for writing down “what I already know” when trying to figure out how something behaves (say a complex regex that I want to match something very specific).
But that said it depends on personal preference, you definitely should not feel bad that you are not doing TDD all the time, no-one is.