February 23, 2017 at 2:02 pm #65098
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?
Hope makes sense.
February 23, 2017 at 2:11 pm #65100
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.
February 23, 2017 at 6:18 pm #65170
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.
You must be logged in to reply to this topic.