A recent bootcamp grad takes on testing.

As mentioned in my latest post, I recently graduated Flatiron School’s Web Developer bootcamp. After the celebrations calmed down a bit, the question that now begs an answer is “now what?”

While going through the program, the question always came up “what are your plans after graduation?” None of us deluded ourselves into thinking that taking one course would magically transform us into 10X web developers; what Flatiron did do a great job with, was turning us into first class learners, and gosh, there's so much to learn.

Whenever those discussions came up, I always joked that I have a huge to-do list of things I need to learn after graduation. The problem is that it's a horizontal list; I want to do all of the things first!

So now that I graduated, all jokes were off, I had to choose what my next focus will be (other than the job hunt for my next developer position of course). Should I focus on brushing up my basic CS skills with algorithms and data structures? Should I go ahead and learn a new language/framework?

In the end, I decided to focus on writing tests.

Why tests?

Let me start by explaining what I mean with tests for my non-technical audience.

Suppose you were making a website. For the sake of this thought experiment, let's pretend all this website can do is allow users to sign up, log in, and log out, and delete their accounts (it's like Facebook but without the annoying parts).

So let's say it took me an hour to put that together, I now have to make sure it works. That shouldn't be too complicated, my site can only do 3 things, so I sign up a test user, log out, log back in with the user I just made, and delete it. Perfect, it all works smoothly, under budget and ahead of schedule.

Now I want my website to do something else; maybe a user should be able to edit her information. So I add that functionality, and to make sure the new feature works I log in with my test user and try to edit the username. That works as well, but wait, I also want to make sure that while coding the "Edit User" feature I didn't break anything else, so I go back to my application, sign up a new test user, log out, log back in with an existing user, edit the information, and delete the user. In the process, I realize that somehow a bug crept in that broke the "Delete User" functionality, so I go back into the code to fix it, and in order to verify that everything is fixed, sign up a new test user, log out, log back in with an existing user, edit the information, and delete the user.

It doesn't take much to realize that this process can get very time-consuming quickly, and it only gets worse as I add more features to my website.

Enter tests

The solution is to automate the process. For every project I make, I would add a test suite. So for my above application, my test suite would contain a script that signs a user up, logs an existing user in, etc.

Ideally, I would aim to have a test cover every feature in my application, so that whenever I make any change to the code, all I have to do is run the tests, and within a few seconds I would have confirmation that I didn't break anything, and if I did, I would know exactly where it was broken so I could fix it.

At Flatiron we dealt with tests a LOT, we read them, ran them, banged our heads when they failed, and celebrated when we got them to pass.

In fact, most of the learning was not done through lectures or books, it was done through a pattern I call TDL (Test Driven Learning, loosely based off of TDD, Test Driven Development). We would start by cloning a GitHub repo, running the test suite, analyzing the error messages, and doing what had to be done to get them passing.

The one thing we didn't do much of, was actually WRITING tests. And that, I believe, is unfortunate. Writing tests is such an important part of writing software, it would have been nice to spend some time learning how to write them properly.

In my last project I did write some tests on my own, but nowhere near as much as I would have liked to. So now that I'm "on my own", I decided to fix that situation. For the coming week or two, I'll be reading up on tests, adding some to my old projects, and maybe even write an entire TDD app from the bottom up.

Based on some friends' recommendations I started reading through Rails 4 Test Prescriptions, if anyone reading this has some more recommendations please do leave them in the comments.

As always, Happy Coding!

This article has been cross-posted from my blog Coding Hassid
You can read more about my coding journey there, or by following me on Twitter @yechielk