hey all – i am back to blogging here instead of using another platform. also i think i will be continue to writing stuff about my career, technologies i am working with and other crap like that. i could occasionally go off script and discuss other subjects, but i guess that’s why it’s my blog. anyway, here’s my post on test driven development.

as part of my career expanding, i’ve had to accept that i need to take on more complex projects that lean more heavily on software development rather than general operations duties. we can have a discussion all day about devops but let’s skip that. for now let’s talk about what i am starting to learn.

chef is a huge part of my day. i am constantly working on, reading or starting a new chef cookbook. it’s been a very difficult road, but every part has been fulfilling. the hardest part of this road has been perfecting testing. testing is a fairly new theory to me as a software tool rather than monitoring tools to validate services. doing chef in a test driven development method is pretty new to me, i was never much of a “dev”

getting to know rspec was like really the biggest part of understanding tests in a chef environment. while i know many ruby developers in the rails world are already very familiar with it, i honestly did not spend much time creating things that required a ton of testing. as i started learning more and more about chef i started to understand a real process of developing software i never really had put much thought in:

while i did write some tests in the past based in bash using “bats” it didn’t really translate to my new gig. but yes, i do understand and love doing tests as part of building systems with chef. i get why it’s so important but let me tell you something that i learned.

chefspec was created to torture me to learn how to write software.

i don’t personally know Seth Vargo, but i do believe he has created a github backed torture device that forces people who do not test code to learn how to test code. but let me explain to you, for the novice it’s not that easy.

“just read the docs, it’s just ruby, it reads like english!”

well that’s what i did of course. i read the docs, wrote the tests, read more docs, read more tests. copied and pasted tests, wrote tests from scratch, got my runners configured and whatnot… it kept giving return fails. when i did get my rspec examples to pass, i would get pr comments about improperly configured runners or poorly used syntax. even worse, my style was terrible. i was getting so frustrated and started getting some nasty anxiety about it… basically it was a dumpster fire.

then i took a moment and talked it out with a peer who gave me some great advice about being part of a segment of “learning” crowd as i move forward and age in the tech industry. he reminded me to continue to improve my quality and it will equate to more success than doing something fast and poor. in the end, he was right. but what was this process doing really? is it getting me to solve a problem or is it get me to be better at what i do?

so i’ve spent a week or so on some tests and started really seeing some success lately. the simple tests of successful converges are things i was able to take on with a very small amount of previous testing knowledge. the more complex conditional types helped me get a greater idea about writing software in general and helped me expand my knowledge just a bit more.

nah i am just joking, i don’t KNOW IT quite the way Neo learned how to do some crazy helicopter stuff in the matrix. but i really have a great base of knowledge today i didn’t yesterday. it hurt a lot. it took me really doubting myself to get to the point where making a negative condition check using a regex string to “not match” in my “with_content” statement made me feel like i was starting to do things a bit more profound.

the road i am going down is bumpy as hell, but it’s pretty fruitful. i’m learning more about me every day when it comes to new aspects of operation and change management systems. there’s more to what i do than reboot, install, maintain and patch. there’s interesting ideas that can be placed into code i can repeat or iterate or refactor. i don’t have to do the same thing over and over. but i do have to make sure it works right the first time.