In pt. 1 of this tutorial, we began by installing Tower.js and everything we needed to make it run smoothly. And we generated our app, letting tower set up our directory structure and create the foundation on which we’ll build the rest of our app. Now we’ll start building out the app, using BDD, a style of programming in which you write the tests first, and learn some of the ins and outs of tower.
So, what will we be building? That’s a good question. Well, tower’s irc channel needed a bot. Something that could log everything said there and post it on the internet so that things we talked about could be saved, and reviewed later. So, we’ll be using Tower to build a very simple irc bot, which logs the conversations and then publishes those to the web, ultimately publishing these as Github Gists.
Because the messages end up as github gists, this means they will show up in google searches, hopefully allowing conversations in the irc channel about problems and questions to be helpful to those searching for such information in the future. Oh, our bot will also welcome visitors to the channel, reminding them to be patient and letting them know their conversations are being published to the web.
So, what is BDD? Well, it stands for Behavior-Driven-Development, and grows out of the term TDD, or test-driven-development. Any definition I give will come far short of actually explaining the concept. I learned about BDD through following the Rails Tutorial, which is something I’d recommend to anyone, regardless of whether or not you ever intend to make Rails apps. In fact, if you are fairly new to programming, or web development, go, complete the rails tutorial, and come back. We’ll be waiting… OK, finished? Good.
As we construct our application, we will always write a test before we actually write the code we are testing for. We’ll leave our tests running all the time, and we’ll know our code is working when the tests finally pass. This is following a pattern known as “red-green-refactor”, coming from the fact that failing tests usually show us red error messages, while passing tests show up in green. After we get our tests to pass, we can then safely refactor or optimize our code, without fear of breaking something. If any of our changes cause a test to fail, we can simply change the code back. If our changes continue to pass the tests, we know that nothing we changed broke anything and that after refactoring, our code still does what we wanted it to. At least, that’s the general idea.
Before we go any further, I want to warn you: I’m no expert on programming, I’m learning too, and while I’ll do my best in this tutorial to follow best practices and good programming habits, I may get things wrong. Constructive criticism left in the comments will be greatly appreciated. However, negative criticism and trolls will be either ignored or deleted.
Get Started with Git
This initiates a new git repo in the current directory. Next we’ll add our files to the repo with:
git add .
Finally we’ll make our first commit.
git commit -m "Initial Commit"
While this will be a “fairly” small app, Git is just so generally useful, I don’t build anything larger than “Hello World” without it. Whether you choose to or not is up to you, but I certainly reccomend it.
Installing Packages and Our First Tests
Next, we need to install a package with npm. This will be very similar to what we’ve done before, but this time we’re installing the package locally, into our application’s node_module directory, rather than globally.
npm install Faker --save-dev
By putting “–save-dev” on the end, we’re instructing NPM to add “Faker” to our package.json, under “devDependencies”. This way, if someone else were to install our app, or we were to deploy it, npm will know which version of which packages to install, and in which environments. Later we will use “–save” to add some packages to our “Dependencies” list, these will be packages necessary in all environments, test, development and production. While we’re at it, let’s go ahead and install sinon-chai. Sinon-chai is a very useful extension to chai that let’s us use sinon’s spies, mocks and stubs in conjunction with chai’s “should” test. We’ll use this in our tests soon.
npm install sinon-chai --save-dev
Next, let’s get ready for our tests. We need open up the project in our favorite text editor. For me that’s:
subl . &
Open up the file test/mocha.opts and modify it to look like this:
Now, open the file “test/server.coffee” and make a few changes to it. We’re going to add “Faker”, “should”, and “sinonChai” to the list of globals, and tell chai to use “sinonChai”, like this:
Now we’ll tell tower we want to create a new model, this one for our ircbot:
tower generate model IrcBot channel:string server:string name:string
This should produce some output in your terminal telling you new files were installed.
Now we make another change to test/server.coffee telling it what to do when the tests call for an ircBot factory.
Now, we’ll see that tower generated some basic tests for us. Let’s run those and see what happens:
mocha test/*/*Test.coffee -w
On OSX, you may need to run the tests like this:
mocha $(find test -name "*Test.coffee") -w
This tells mocha to run any tests in the subdirectories of the test folder that end in “Test.coffee” and to watch for any changes in our project, and run the tests again each time changes are saved. You can also run our tests via the nifty command to npm that tower inserts in our app’s package.json, simply with:
However, this only runs the tests once, and doesn’t produce output quite as pretty as we get otherwise. It is very handy, though, for running a one-off set of tests after making a change to an existing project.
After running the tests, you should see that some of our tests are currently failing:
Let’s fix those quickly and call it a night. All we have to do is open the file test/models/ircBotTest.coffee and change the line “new App.IrcBot”, which is based on old syntax to “App.IrcBot.build” which will use the code beneath it to fill in the bot’s attributes. Like so:
Now, instead of seeing bright red tests urging us to fix something, we should see lovely, pretty green tests telling us that everything is ok and we can stop here for now.
Come back for Part 3, where we will create some tests of our own, and begin to give our app some functionality.