TDD Nitty Gritty

Last week I had a very nice exchange with two other developers (Valkyrea and Mark, thanks for the discussion!) about learning to code. We talked about the paths we’re taking and the progress we’ve made. I am fascinated by the breadth of available knowledge in this field and the multitude of ways that knowledge can be acquired. I think it’s fair to say that the three of us in that conversation are at roughly the same depth, but we have chosen to focus on different aspects. Hopefully, we continue meeting and talking about those things. It is incredibly important to share and support each other, and I think we would derive huge benefits from those kind of discussions.

One of the topics that came up was Test-Driven Development; what it is and how to get started with it. I initially sat down to start from scratch and talk about TDD as a philosophy and how to get it set up. That made me a little nervous, mostly because I am still very much a beginner, just scratching the surface of TDD. I also realized that I had covered most of what I know about TDD in my first article on the topic. Rereading the article, I could have inserted more detail, but it is still a pretty simple process. So here is some of that detail that was missing.

(I am running a Windows 7 desktop, a Windows 8.1 laptop, and using JetBrains’ WebStorm IDE, some steps and details may vary depending on how closely your environment matches mine.) First step is downloading and installing nodeJS. Pick your poison, I used the windows 64bit installer. The installer claims it will set up your PATH, and on my desktop, that seemed to work, on the laptop, it did not. So the next step was to set up PATH for npm. I did that right inside Webstorm’s terminal, although you cna use whatever CLI you feel comfortable with. The command I used was:

 set PATH=%PATH%;C:\Program Files\nodejs

Again, use whatever address you need to make it work. Once node is installed and pathed and ready to go, you can use npm to install mocha. It is also dead simple:

npm install -g mocha

That’s a global install so you can use it in any project from there on. At that point it should (might?) work. It was long enough ago that I forget if I had to do the next steps on the desktop, however, I did have one more step for WebStorm on the laptop. I opened up the settings (ctrl-alt-s), navigated down into Languages & Frameworks -> Node.js and NPM and set the path to the node interpreter:

C:\Program Files\nodejs\node.exe

and then double-clicked the mocha package and selected install. I don’t know why that was necessary, it is possible I missed a command or step that would have done that automatically. I do know that once that step was complete, I could drop into the terminal and type “mocha” and it ran.

 0 passing (4ms)

Perfect!

I am still running without a test runner, and in a few other … lightweight ways, for lack of a better term. This isn’t really from any desire to keep it light or an informed decision or anything, I just haven’t spent the time figuring out how to get a runner working. I would like to, and I should get on that soon. I am hoping it integrates as well in WebStorm as I saw in Visual Studio. Grain of salt time, my friend Chris is using the Ultimate Version, and so it could be that some of the features I saw are high-level. Things like live-updating test status (which sits in the gutter) as he typed and running tests on save, etc. I won’t know until I get it running, but I will certainly share my findings when that happens!

I also got to spend a little time talking to my brother, a veteran programmer and informal TDD evangelist about my test writing and process and he gave me a lot of good advice to chew on. I will be rewriting the testing in my blackjack program to be more granular and more verbose. I have been trying to keep things “readable,” but I worry sometimes that I might be tempted to go overboard. It was nice to hear him tell me to make it even more readable.

Questions, comments, criticism and requests for clarification are always welcome. If I skipped over some vital steps or you followed everything and it still isn’t working, let me know. If you want more detail about some aspect of the process or insight into how my brain works, I’d be happy to oblige.

Keep coding, keep learning and keep writing about it! Sharing your stories helps all of us grow as programmers and as people!

Advertisements

One thought on “TDD Nitty Gritty

  1. The live test updating/running is via a produce called nCrunch. nCrunch is awesome but won’t help with JavaScript. The other features I use are available in Visual Studio Community, and I know they can work in WebStorm, too.

    It really depends on if you want your workflow to be from command line or from an IDE. There really is no right answer to this. It’s a lot like the home theater components vs. theater-in-a-box. You can get set up in WebStorm, Visual Studio, Sublime, Brackets, etc etc to be like your “flight deck” that you never leave and automates a ton for you. Or you can do what you need, when you need it at a command prompt.

    And these worlds are coming together in a big way. All of the major ides are opening up to integrate the small, single purpose tools that operate at command line anyways, so very soon you’ll build what you want out of lego pieces.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s