Test-driven-development is blowing my mind

Over the past couple of days, we’ve been learning about test-driven-development (TDD). Tests, as I’ve come to learn, are written to test whether your code (specifically, the methods) works properly. In some cases, the same person writing the code writes the test. In other cases, you may pair up with another dev and ping-pong the writing: first dev writes the test, second dev writes the code, and then switch.

Testing code is completely new to me. So far in class, we’ve been writing apps in Ruby without tests. So learning about tests has blown my mind on two levels. First, the concept of testing and it’s potential for helping to state objectives and clarity of function is really exciting. Jay also mentioned how tests can aid communication between developers and save time when it comes to adding new features to an app. All that sounds very good and useful and is on the positive side of my mind being blown.

The second way in which my mind was blown is realizing that it’s more work! Just a whole lot more code to write and in a form that is different from the syntax we’ve been using. That’s on the negative side of my mind. I had a feeling of slight discouragement in realizing that it existed, which is kind of funny. I’ve been bombarded with new concepts and vocabulary and all kinds of things for the duration of this class, but this one thing in particular incited a negative feeling. It’s not so much a matter of trying to avoid work. That’s not it at all. It’s more a matter of feeling a bit overwhelmed; of being in the throes of trying to wrap my thinking around one thing and then having this other thing pop up. Even though they are supposed to work together, getting the logic down to make them work together is the challenge.

To be fair, I’ve only known about testing for two days, but with everything else we’ve learned, I’ve had an understanding of the logic and basic execution pretty quickly. With testing, it felt like it was an inversion of what I was learning, as if I had to recalibrate my thinking to accommodate the way testing works. It’s taken me a while to figure out how to execute the tests in the few examples we’ve covered. When Jay goes through the example with Rspec, it makes perfect sense, but when I try it…not quite.

In the strict sense, TDD is supposed to start with a test before any code is written. The test is meant to fail, then from there you start developing your code to get the test to pass. In that vein, I suppose I can view my initial failure to grasp and execute testing as a meaningful first step. Now I have to figure out that second part of getting the test to pass.