Testing JavaScript With Jasmine Part 1

Hello everyone,

At Columbus Code Camp 2014, I was given the opportunity to speak. The talk name is “Testing JavaScript 101”, which involves testing with Jasmine in a TDD and BDD fashion. This will be an overview of that talk, and will provide links to the materials for further study.

First, let’s talk about Jasmine itself. Jasmine is a testing framework for JavaScript that is primarily focused on BDD-style testing. This is especially beneficial in a world where one would want to show non-technical people what they are testing and prove that they pass in a way anyone could understand with relative ease. It’s also quite good in that it doesn’t rely on any browser, the DOM or any JavaScript framework. So, it can run wherever JavaScript can run.

In order to install Jasmine, there are three choices:
    1. Using Git: git clone https://github.com/pivotal/jasmine
    2. Using Ruby: add the Jasmine gem to your gemfile and bundle install
    3. Using Python: use pip or add it to your requirements.txt

For the sake of this post, I’ll be explaining the Git route. Once Jasmine is cloned, go to the directory you cloned it in and unzip the file. A few directories (lib, spec, src) and the SpecRunner.html file are the result of the unzipping.

Thankfully, the folks at Pivotal Labs made it pretty easy to jump into this, as they already populated the spec (tests) and src (code) folders with examples. You can immediately run the SpecRunner.html and see an example of passing tests. Which brings me to my next point: test runners. For the sake of this post, we’ll be using the SpecRunner. However, other test runners can be used. đŸ˜‰

At some point, I’ll be using jQuery in this project. It’s quite easy to add that into this project as well. We edit the SpecRunner file in your favorite IDE or text editor (I’m partial to Sublime Text 2 for simple JavaScript work), and add this near the top of the file with the rest of the scripts:

<script type="text/javascript" src="http://code.jquery.com/jquery-latest.min.js">
</script>

Now that we’ve gotten all the installation out of the way, let’s take a quick peek at the examples. You’ll notice all the tests are in the spec file (short for specifications) and the code is in the src file (short for source). If we look in the source files, there’s not much but some short functions that are used just for showing off the tests. They don’t do much but set values or throw errors. In the spec file, we first see a ‘describe’ keyword. The ‘describe’ block of code has a title and a function. The function will hold all the actual tests. So, in essence, ‘describe’ blocks are suites of tests (which we’ll see in more detail later).

The actual tests are in ‘it’ blocks. These also have a title and a function, with the exception that the testing happens in this function. The title traditionally follows an “it should do this” syntax, describing the behavior that the test is trying to flesh out. The ‘expect’ value is what is being tested, and that is followed by the matcher. Jasmine has many matchers that I’ll go into on the next post. For now, we’ll go over just one of the ones that’s in the example:

describe("Player", function() {
  var player;
  var song;
it("should be able to play a Song", function() {
    player.play(song);
    expect(player.currentlyPlayingSong).toEqual(song);

In this case, we have a test suite titled “Player” and a test called “should be able to play a Song”. This is calling to the play function in the player file, which is setting the currentlyPlayingSong variable to song. Our test expects that the player.currentlyPlayingSong variable will equal song. That is true, so we get a passed test:

Jasmine_Testing_example_1

Thus far, we’ve installed and ran a test, knocking the first crucial steps out. Next time, I’ll go into further detail on what’s possible with matchers, talk a bit on the more advanced features of Jasmine, and give some resources for further study and practice. Please feel free to comment if you have any questions or comments.

Thanks for reading!

Advertisements

First Days As A Developer…Kinda

Hello All,

As some of you who may know, either from my previous post or from speaking to me in person, I am now working with Improving Enterprises. Thus far, it’s been an enjoyable experience, full of learning and a pretty good amount of fun. Honestly, I was hoping to make this change sometime before or after Jen and I had our daughter. The reason, as you all may know, is that babies don’t allow for long lengths of sleeping or peaceful silence. This can make other scenarios (like changing careers and starting at a new company) a bit more challenging. However, with the help of God (to keep me patient, calm, full of gladness and focused on what’s important), my wife (to keep me sleeping and laughing, supporting me all the way, and having some occasional fun) and friends (to give us a break every once in awhile), I’ve been doing pretty well. To pay back some of that kindness, I’ve forced Jen out for a few hours to go have fun with friends while I watch the kids. Thankfully, it’s nap time, so I’m blogging đŸ™‚

Moving back onto topic, I’ve been positioned at a really great company called IGS Energy. They’re a gas and electricity supplier, among other things, which you can find out at these links: Website, Facebook, Twitter, LinkedIn.

Currently, I’m performing testing and QA work for them at the moment. Even though this isn’t exactly what I was expecting when moving over to Improving, I feel this is the best move for my scenario. The reasons I think so are as follows:

1.) I’m working on an Agile team. This is something new to me, so I can become accustomed to standups, 3 Amigos, quick releases, extensive communication and all the stuff that comes along with it.
2.) I’m working on an actual team. This is quite different, since my last job wasn’t exclusively development, and I didn’t exactly have a team to work with. It was just me and my boss, so getting acquainted with relying on multiple people and keeping up with communication is something that I’m glad to be getting re-accustomed to.
3.) Testing. Even though this was a part of my development experience thus far, it’s always a good thing to grow in your testing skills. Having a mentality of keeping everything of good quality will only help to bolster my development career.
4.) More time to grow. Considering my newness to the field, it would only benefit me and the first team I work on for me to learn and grow as much as I can. Thankfully, the group at IGS has been willing to answer my questions and help me out thus far, making my growth much easier.

On top of these reasons, I’m also spending time doing development on the side, which is satisfying my dev itch. I’m currently working on a Windows Phone game (will probably go cross-platform with it at some point) that I started during the last WinDevUG meeting I went to and working on Guy Royse‘s vending machine kata, which I started at the last CbusJS meeting with Greg Malcolm.

All in all, I’m happy with the way things are going, and excited to see where things go.

Well, the kids are up, and it’s time for dinner. Thanks for reading!