Using Sinon’s Spy and Stub in Mantra (Unit Testing)

With the release of Meteor 1.3, unit testing has never been easier in Meteor. Our team recently decided to adopt Arunoda’s Mantra spec for developing Meteor applications. It is an application architecture which allows for a more modular approach with clear separation of concerns with the client and the server side. It has been a rough month for us since the spec is new and there are limited learning resources available. There were also a lot of things to learn since adopting the Mantra spec meant that we have to learn React for the presentation logic, instead of sticking with Blaze.


Unit testing is something that can be easily accomplished with the Mantra spec. Since it is modular and it clearly separates the presentation logic from the business logic through containers, components and actions, everything can be unit tested. Meteor 1.3 also introduced native NPM support, which means that using familiar tools such as Mocha, Chai and Sinon can be imported in a straightforward manner. This is going to be my first blog post and so I am only going to explain Sinon’s spy and stub methods as they were used in Arunoda’s mantra-sample-blog application.

Spies

People who are new to unit testing tools in JavaScript (with me included) were initially confused about the difference between Sinon’s spy and stub. It turns out that a spy is a basic function that you can use in Sinon, and that stubs and mocks were built on top of it.

According to the Sinon.JS documentation, a spy is

a function that records arguments, return value, the value of this and exception thrown (if any) for all its calls. A test spy can be an anonymous function or it can wrap an existing function

What this means is that a spy can be used as a replacement for an anonymous callback function or you can wrap an existing function into it so that you can spy on its behavior. For example, if you have a function that accepts another function as an argument to be called back later after a certain condition, you can instead pass Sinon’s spy() function as the callback. You can then assert or use Chai’s expect() to see if that function was called by using spy()’s calledOnce(). Additionally, you can check if the correct arguments were passed to it by using its calledWith(). You can check the different spy functions that are available here.

Now let’s look at how spies are used in the Mantra sample blog application. We are going to use the tests that were written for the posts action. Let’s check this code snippet out:

it('should call Meteor.call to save the post', () => {
  const Meteor = {uuid: () => 'id', call: spy()};
  const LocalState = {set: spy()};
  const FlowRouter = {go: spy()};
  
  actions.create({LocalState, Meteor, FlowRouter}, 't', 'c');
  
  const methodArgs = Meteor.call.args[0];
  
  expect(methodArgs.slice(0, 4)).to.deep.equal([
    'posts.create', 'id', 't', 'c'
  ]);
  expect(methodArgs[4]).to.be.a('function');
});

In the test block above, we are testing if our action will correctly invoke a Meteor Method in the server through Meteor.call(). The first three lines are creating local objects for MeteorLocalState and FlowRouter to be used exclusively in this test case. In the Mantra spec, these are exported as the application context inside client/configs/context.js.

Actions in Mantra receive this application context as the first parameter. We are creating local objects in lieu of the real app context and by doing so, we can trick the action into thinking that it is receiving its first expected argument (which is the app context).

Next, we spy on how these objects are used inside the action that we are testing. See how the Meteor object that we have passed contains a call property, which is a Sinon’s spy() function? When the action gets invoked on Line 6, it will go ahead and invoke Meteor.call() inside it. The Meteor object that it will receive is something that we have just created for spying purposes, so we have access to the arguments that were passed into it when it was invoked (Lines 7 — 12). We used the arguments that we have obtained through spying to verify that our function is invoking Meteor.call() with the correct arguments.

This is what the create action looks like, for reference:

  create({Meteor, LocalState, FlowRouter}, title, content) {
    if (!title || !content) {
      return LocalState.set('SAVING_ERROR', 'Title & Content are required!');
    }

    LocalState.set('SAVING_ERROR', null);

    const id = Meteor.uuid();
    Meteor.call('posts.create', id, title, content, (err) => {
      if (err) {
        return LocalState.set('SAVING_ERROR', err.message);
      }
    });
    FlowRouter.go(`/post/${id}`);
  }

Stubs

Now that we are done with spies, and have a basic understanding on how they work, let’s work with stubs. Stubs are just like spies, and in fact they have the entire spy() API inside them, but they can do more than just observe a function’s behavior. According to the Sinon API, stubs are:

functions (spies) with pre-programmed behavior. They support the full test spy API in addition to methods which can be used to alter the stub’s behavior.

and they should be used when you want to:

Control a method’s behavior from a test to force the code down a specific path. Examples include forcing a method to throw an error in order to test error handling.

or

When you want to prevent a specific method from being called directly (possibly because it triggers undesired behavior, such as a XMLHttpRequest or similar).

Okay, so where spies can observe and spy on how a function is going to be called, the number of times it’s going to be called and the arguments that were sent with it, stubs can do all these, plus you can also programmatically control its behavior.

Let’s check how it is used on the post action test inside the sample blog application:


    it('should call Meteor.call to save the post', () => {
      const Meteor = {uuid: () => 'id', call: spy()};
      const LocalState = {set: spy()};
      const FlowRouter = {go: spy()};

      actions.create({LocalState, Meteor, FlowRouter}, 't', 'c');
      const methodArgs = Meteor.call.args[0];

      expect(methodArgs.slice(0, 4)).to.deep.equal([
        'posts.create', 'id', 't', 'c'
      ]);
      expect(methodArgs[4]).to.be.a('function');
    });

This particular test will check if our action will set an error message if something goes wrong after the Meteor Method call. Just like what we did with the spy example, we are setting local objects to be used as the context for our action function.

In Mantra, the LocalState is a Meteor reactive-dict data structure (a reactive dictionary) which is mainly used to handle the client side state of the app, although it is mostly used to store temporary error messages. We are creating a LocalState object here to mimic the app context’s LocalState. We are setting its set property as a spy function, so we can later see if our action will set the appropriate error message by checking the arguments that were passed into it.

Notice that this time, we are using a stub() instead of a spy() for our local Meteor object. The reason for this is that we are no longer just observing how it is going to be called, but we are also forcing it to respond in a specific way.

We are checking our action’s behavior once the call to a remote Meteor method returns an error and if that error will be stored in the LocalState accordingly. In order to do that, we need to reproduce that behavior, or make the call() function in our local Meteor object return an error. That is something that a spy() will not be able to do since it can only observe. For this scenario, we will use the stub’s callsArgWith()* function to set our desired behavior (Line 6).

We will give callsArgWith() two arguments: 4 and the err object that we have defined in Line 5. This function will make our stub invoke the argument at index 4, passing the err as an argument to whatever function is at that position. If you are going to look at our create action above, Meteor.call() is invoked with five arguments, the last or the one in the fourth index is a callback function:

Meteor.call(‘posts.create’, id, title, content, (err) => { 
  if (err) { 
    return LocalState.set(‘SAVING_ERROR’, err.message); 
  } 
});

We have to remember that this Meteor.call() that is being invoked here is the local object that we have created and passed explicitly into our create action for testing purposes. As such, this is the stub in action, and it doesn’t know that the last argument when it is invoked is going to be a callback function, so we have to use the callsArgWith() with the err object. Inside this callback, the create action will then store the error message in the LocalState object that we have passed in. Since the set() function of that LocalState object is a spy, we can conclude our test by checking if the arguments that were passed to this spy function matches the error message that we are expecting (Line 9).

This wraps up our discussion of how Sinon’s Spy and Stubs methods are being used in Mantra Unit Testing. As a recap, a spy just observes a certain function, or can take the place of a anonymous callback function so we can observe its behavior. A stub does more than that, by allowing us to pre-program a function’s behavior. If I have provided any wrong information, please feel free to correct me in the comments. :)

*The callsArg and yields family of methods have been removed as of Sinon 1.8. They were replaced with the onCall API.

How To: Play MP3 and other codecs on Moblin 2.1

Moblin (short for Mobile Linux) is a new Linux distribution that is designed by Intel to support multiple platforms and usage models ranging from Netbooks to Mobile Internet Devices (MID), to various embedded usage models, such as the In Vehicle Infotainment systems.

Moblin 2.1 was released recently and you could check out the screenshots hereor watch the intro video here for a quick look on how the Moblin 2.1 Netbook looks like. You could check for tested netbook models here. The full release note and download link could be found here.

Looks promising, but the problem is, as with any other Linux distributions, it does not play mp3 and other proprietary codecs out of the box for legal reasons. It only plays Ogg Vorbis audio and Ogg Theora video upon installation and the Gstreamer packages needed to play mp3 and other video codecs are not available from Moblin's repository or from the Moblin Garage. So we have to compile these packages from source.

DISCLAIMER: Try this at your own risk.

Step 1: Download the souce code here. We need the following source codes:

gst-ffmpeg-0.10.9.tar.bz2
gst-plugins-bad-0.10.16.tar.bz2
gst-plugins-base-0.10.25.tar.bz2
gst-plugins-good-0.10.16.tar.bz2
gst-plugins-ugly-0.10.13.tar.bz2
gstreamer-0.10.25.tar.bz2

After installing these, extract them to a directory of your choice (ex. /Home/Downloads).

Step 2: Open the terminal and type this command to download and install necessary development tools and build packages:

yum install gcc bison flex *glib* *diff* liboil*dev*

Step 3: Compile and build the source code. Using the Terminal, use the cd command to navigate to the folder where you have extracted the downloaded source codes (ex. cd /Home/Downloads). Then type these commands in order (press Enter after each line):

cd gstreamer-0.10.25
./configure -prefix=/usr && make && make install

cd ..

cd gst-plugins-base-0.10.25
./configure -prefix=/usr && make && make install

cd ..

cd gst-plugins-good-0.10.16
./configure -prefix=/usr && make && make install

cd ..

cd gst-plugins-bad-0.10.16
./configure -prefix=/usr && make && make install

cd ..

cd gst-plugins-ugly-0.10.13
./configure -prefix=/usr && make && make install

cd ..

cd gst-ffmpeg-0.10.9
./configure -prefix=/usr && make && make install 

Then reboot and have fun with your media. I might write an automated script later to do all of these upon execution of the script, but I'm busy at the moment.

Random Linux Post

"'Free software' is a matter of liberty, not price. To understand the concept, you should think of "free" as in 'free speech,' not as in 'free beer.'"

We all grew up using one Operating System, and I am pretty sure that the new blood still does. Maybe not all of us, but at least in my generation, at least 99.8% grew up using one Operating System. And yes, I am referring to Microsoft Windows.

Personally, I do not have any problem with Microsoft Windows. I grew up using it and Macintosh, but I've only used Macintosh in my early years, as far as I remember, when I was still in Grade 2. It was a lot easier to use as compared to Windows, for it uses a lot of graphics, unlike Windows which tends to focus on words and phrases. Windows offers clear explanation for each, though nothing beats that power of imagery and intuitive icons. If I am not mistaken, Macintosh has first introduced the Graphical User Interface or the GUI, for I remember my mom back in the days using Windows 3.1. It uses Command Line Interface and I remember using a Mac computer then which already has a black and white GUI.

You might be wondering by now why I am talking about these two Operating Systems when I should be explaining why I switched over to a new one which only a few people knows that such OS exists. Well these two OS are the most popular and people find it peculiar why I switched over to a "not-so-popular" OS, at least on where I live. Most reaction I get from people is a smirk, followed by "Is it easy to use Linux? Some people said they had a hard time using it" and such, and some people even look at it as inferior as compared to Microsoft and Macintosh and they are really skeptical when it comes to performance. Well, here's my defense.

The notion that Linux is hard to use is like 20 summers ago. Some people still refer to Linux as a pure Command Line Interface OS, and does not have a good GUI like the two popular OS I have mentioned above. If you are still under that impression, you might be living under a rock for decades! I could say that Linux has better GUI than any OS I have used because it gives you choices. What do I mean? Instead of the usual taskbar with Start menu with icons on the desktop or the clean desktop with a familiar dock, in Linux, there are several Desktop Environments that you could choose from, each of them has an array of features that is suited to your preference or hardware. For instance, there is the traditional GNOME desktop environment which is common on most Linux distributions. There is also the K Desktop Environment or KDE which is targeted to new Linux users who are well accustomed in using Microsoft Windows. Plus there is also the XFCE desktop environment which is becoming popular in the past few months. It is an extremely lightweight desktop environment which could bring an old computer to life, for the applications that are bundled with it uses less memory consumption and requires less processing speed. There are endless customizations that could be done on each of the desktop environments I have mentioned and you won't get bored; you can get the look that you want and need. And, you won't ever have to go into suspicious sites again looking for cracks and or syndicated Serial Numbers for your software since everything is free in Linux. Well, almost all are free, only a few programmers charge for their programs and they come real cheap if they does.

Speaking of cracks, well in Linux, you don't need them so no need to bother. I know some of us ( and I should say a lot of us here ) have used pirated software, pirated OS and all things that are not that legal and I should say I grew tired of it. It's like this: Why would I use such commercial OS when I cannot really afford it? I mean how much is OS X or Vista these days? That's only the core OS, how about additional productivity software, which are sold separately? Being street smart, we could always manage to get some "cracked" or "stripped" or worst "pirated" versions, but come on, show the programmers some respect. They certainly need the money that's why they chose to work there. And why count on them if there are ones out there who are willing to make authentic software for all of us to enjoy for free? All they need is support. And they are going to support us back.

Another thing that made me switch to Linux is speed. I know, this statement of mine might trigger a lot of grunts and "Come on"s from a lot of people since they believe that the computer's hardware is responsible for that, meaning that if you have a great specs, then it would be great with any OS and vice versa. Well that might be true, but I am sure that a new Windows box would run like a charm the first few days and then after a week or so, it will start to lag and faster boot times might then be noticeable. It is caused by the fact that there are thousands of viruses and worms known in Microsoft, while there are only around 400 known viruses in Linux and Mac OS. That's just a rough estimate.

Add all those useless services (programs that run in the background) that came installed in Windows XP and you'll get a boot time close to five minutes.

Well...

The Support system of Linux is really interesting. Instead of calling a number and paying for Tech Support Representatives, all you have to do to get support is to have an internet connection. In Linux, you get support from the user community and not from hired technical people. You just need to register in your distribution's community forum and fire your questions their. Help would be there in 1-2 hours time, and in several week's time, you'll see yourself gaining familiarity with the Linux distribution that you have chosen and you'll see yourself hanging out in the community forums, helping newcomers out.

There are a lot of great things I could mention about Linux, but let me clarify things out: Linux is just the kernel used, and not the OS. A kernel together with the bundled software makes a so called distribution. Those distributions that uses the Linux kernel are Ubuntu, Fedora, Mandriva, Debian, OpenSUSE and etc. Among the most famous are Ubuntu, as they said it is the most user friendly and I have to admit that it has a great community. Personally, I use Fedora, not because Linus Torvalds himself and all the computers at NASA uses it, but I guess I just got used at using it and I feel uncomfortable using any other distributions.

Linux and Open Source OS and applications seems to be more popular now than ever due to the sudden boom of netbooks and other low priced portable devices that comes with Linux pre-installed.

To end this post, I would say that GNU/Linux would be the future of computing, it does not solely give us free software, it also gives everyone an idea of how everything works inside the box.


Installing Cairo-Dock on the Acer Aspire One

Cairo-Dock is an OSX-ish application laucher that you could place on your desktop to replace your panel. Or if you're like me, you could have both and will make your desktop similar to this [It is recommended to have at least 1GB of RAM though]:

Hopefully, it is fairly easy once you have activated the standard XFCE desktop and set aside the Acer modified desktop, instructions on how to do that could be found here. Of course, this is assuming that you already have added the new RPM-Fusion repositories, if you haven't yet, then simple instructions could be found here.

Once we have the standard XFCE desktop, we need to activate Compiz [it is a program pre-installed and can make great 3D effects on your desktop] by downloading Fusion-Icon. Just go to the Terminal and then type in:

sudo yum install fusion-icon

After installation, we can run it by pressing Alt+F2 on your keyboard and then typing in fusion-icon and then click Run. You will know if it is successful if you see a new blue icon on your system tray [where the clock, etc. is]. You can right click it for you to configure some effects that you might like to enable. If you might ask and be interested what Emerald theme is, it is a theme manager and you can get themes for it by opening the package manager and searching for emerald-themes. Later on this guide, we are going to add fusion-icon and cairo-dock so that they would run automatically upon startup.

Now that we have fusion-icon, all we need to do is to get the cairo-dock RPM from any of the mirrors listed in here. After downloading it, just double click it and it will automatically installed. You can find it in you menu under System, named Cairo-Dock. Click on it and then the dock will appear in your desktop. Right click it so that you can personalize it and adding applications is as easy as dragging and dropping .desktop files from /usr/share/applications to the dock, or you can create manually configured lauchers/subdocks/etc. if you want.

Themes for it are also available, try searching some at http://rpm.pbone.net/ by typing in cairo-dock-themes. I got my themes there but I forgot the direct link, but I'll update this later.

Now if you notice, fusion-icon and cairo-dock does not open upon startup. This can be easily remedied by opening a Terminal and typing:

xfce4-autostart-editor

A new window should pop up and just add those two applications, the commands being cairo-dock and fusion-icon, respectively. And that's pretty much it.

Have fun on your new desktop!

Installing Mozilla Thunderbird and Pidgin on Acer Aspire One

This How-To is Acer modded Linpus Lite specific, please don't try this on an Acer Aspire One that has Microsoft Windows XP or Vista installed.

This How-To will guide you in installing Mozilla Thunderbird and Pidgin Messenger in your Aspire One and change the icon on your desktop to the original icon. This will only work assuming that you are still using AME or the Acer e-mail client that came pre-installed with your Aspire One and the Acer Messenger as well.

First thing that we need to do is to uninstall AME, by typing this command in the Terminal [alt+f2 and then type Terminal and then click on Run]:

sudo yum remove evolution-data-server libpurple

When the terminal is finally done performing those task, we can go ahead and install Pidgin and Thunderbird using pirut or in my case the Smart Package Manager [assuming the you have already signed keys using this command: sudo yum update fedora-release]. Open pirut or Smart and then search for Pidgin and then Thunderbird. After we're done with that, we're going to associate both programs with the default Mail and Messenger icon by typing these commands on the Terminal:

cd /usr/acer/bin

sudo ln -s /usr/bin/thunderbird AME

sudo ln -s /usr/bin/pidgin UIM

Well actually, it is as easy as that and we are done. You should now be able to use Mozilla Thunderbird and Pidgin using the default icons, but in case you are unhappy with those icons and wants to have the original icons, don't worry because we can do that by going to the Terminal and then typing:

sudo mousepad /usr/share/applications/AME.desktop

It should open a notepad that has a lot of text written on it and just in case you want to label the icon differently, let's say change it from E-mail to Thunderbird, just replace the text after Name= and GenericName= to your preferred name. Let's get back to the icon. When we scroll down, we should be able to see a line that says Icon= , just replace it with thunderbird.png, save it and we're done. Well, sad to say for Pidgin it has to be done in a different way and I'll just cover that on my next post, because it involves tweaking of group-app.xml, and a single mistake can ruin your desktop.

If you're already satisfied, then that's all, however for additional info, you can read below.

So now we have Mozilla Thunderbird and its original icon, what to do next? Well this is not that necessary but just in case you found out, the Mozilla Thunderbird we just installed does not update itself automatically and if we check on the Help menu, Check for Updates is grayed out, that is due to the fact that this version of Thunderbird is from the Fedora 8 [the Linux distribution where Linpus is based] repository. So in order for us to fix this, we need to do these steps in the Terminal so that we will be getting the official release from Mozilla and we're going to install it in the /opt directory. This is how:

wget "http://download.mozilla.org/?product=thunderbird-2.0.0.17&os=linux&lang=en-US"

sudo tar -xvf thunderbird-2.0.0.17.tar.gz --directory /opt

And then a lot of unpacking happens. After it's done we can type this again in the Terminal:

sudo chown user -R /opt/thunderbird

sudo mousepad /usr/share/applications/AME.desktop

And we just need to change the Exec= line to look just like this:

Exec=/opt/thunderbird/thunderbird

That's pretty much it. But if you're bothered to have 2 Mozilla Thunderbirds installed in your Aspire One, we can delete the old one via pirut or Smart but it will delete the icon as well which can be remedied easily by searching Google these keywords that I have used which is 'thunderbird.png 64x64'. Just copy the image to your Downloads folder and then move it to the pixmaps directory using this command:

sudo cp /home/user/Downloads/thunderbird.png /usr/share/pixmaps

After that, we're done. Have fun!