Jasmine-node not picking up expectation

Today it’s a quick one. It bite me few times already so it deserves a post, if not to help you, then to make me remember.

Sometimes I write simple test for parameter-less function and then jasmine-node sees the test, but do not recognize assertion, reporting something like
1 tests, 0 assertions, 0 failures
while clearly I have some assertions (a.k.a. expectations) defined! See code below:

I’m so used to CoffeeScript right now that all seems to be OK for this code. Yet there is an issue in here. TDD want’s me to write failing test first so it is easy to spot that test passes even though it should not so seeing green test when I expect it to be red indicates that something is wrong). Can you see what’s wrong?

CoffeeScript allows to call function without using parenthesis – it automatically adds them to include all rest of line as parameters. Pretty nice when used good, code seems clearer, more readable once you get used to it (at least to me, at least now). But here it bites us. You see, when function takes no parameters providing parenthesis to call is obligatory – they won’t be added automatically since it would make returning function impossible (or it would require different language feature to return function pointer, which would not be obvious for developers).

Correct code, that actually calls assertsions is presented below:

See what changes? Two sets of parenthesis added: one to call getValue and the other to toBeNull – since both are parameter-less! Now we finally get red test, as expected. Hope I will remember it next time.

Require and html test runner

Last time I’ve shown how to configure everything so that multiple files can easily be used to separate classes and how tests can include all required code by taking advantage of jasmine-node and nodeJs test runner. We left it with test running fine but noting that this will not work for html test runner. Let’s see how it should be configured to check if I was right

First thing we will need will be jasmine code to make it all work – obviously. We can get it for free (awsome MIT license) from github: jasmine downloads (if it is not working go to main project page jasmine and try to find where they moved download page). I’ve downloaded latest version available (1.3.1 at the time of writting this post) and unpacked it in my ./spec directory. This zip file contained required javascript code to run the tests as well as SpecRunner.html file with preconfigured file and dependencies for fast and easy runnig specifications. There were also included some example specs and source codes but I’ve removed those as not needed.

When opening SpecRunner.html file we can see that it’s just an ordinary html file with included styles and javascript – jQuery and jasmine so that everything is working and looking nice. There are also example of specifications and source code inclusions – but I’ve removed those since I’ve removed sample files, like said before. Closer to the bottom we can also see javascript function. I did not read it in details but it creates some test runner, configures it and fires it – all the details are in jasmine.js file.

Seeing two sections – one for source files and the other for specifications – I’ve added references to my files I wish to run in this test runner.

As you can see those references lead to lib directory – it is output directory for my compiled files (which I compiled simply by calling coffee --output .\lib --compile .). Suppose that you do nothing more and just open the file in web browser – it should run all specs included. Try that and see.
I did and I got empty page and few javascript errors – require is not defined. Sure it’s not – it is nodeJs function not present in jasmine by default. And we do use it in our specifications and classes. More – even if this method was defined it probably would not work as we hope it would – exports class would also not be defined as we use window object to pass references to our classes when running outside nodeJs (see previous blog).

But think about that for a second – what’s the point of using require function in first place? To include other files. But we already included them in html definition so they are ready to use. We’ve taken care of exports object not being defined also by using window object. Solution to the problem seems pretty easy – write simple require function that will return reference to window object and rest of the code can stay unchanged. So I did – added this little snippet below jasmine references in runner file:

Why does it work? Because javascript is dynamic language that tries to fit whatever it can wherever it can. You call require function – cool I have one, I will run it! It does not even care that function signature does not match – apparently it does not need all those arguments you’ve provided so why bother. Return value type is different (window is for sure different class than exports) – not a problem, I don’t care – it says – I just hope you know what you’re doing. And we sure know – just accessing properties that we’ve attached ourselves to the object. We’ll be fine.

Running the SpecRunner.html file in web browser again shows us report from test running – all specifications passing (hopefully!) and everything is green. Cool!

And that’s why dynamic languages are so fun – no need to worry about interfaces, types and everything else when all you need to do is some small hack to make some libraries work in different environments. Pretty clean hack I think in this case. Of course including to many of those is not a good idea. One still needs to follow good practices of development process. But that’s not the point. The point is when you need to do something simple – it is exactly this – simple! All script languages should be like this – and not some weird C implementations with all kind if limitations and stuff you need to worry about

So that one was simple. I think my code files organization needs some small update for better looking references – but that’s simple. I’m just happy to see everything running OK with so little work required. We will see what’s further on the road. ’till next time!

CoffeeScript – organize multiple files

I’ve recently started working with CoffeeScript and wanted to do things right. This means writting some tests and generally trying to follow TDD practices.
Code needs to be modular – that’s pretty obvious for anyone who ever worked with something else then tiny “hello world”-like programs. Having 1k Lines of Code in a file is pain. With 5k LoC it seems almost impossible to work effectively. And even more – I definitely like having my tests in separate files than my production code. So I my project structure like this:

-BounceToTarget
-spec
Ball.spec.coffee
Ball.coffee

For now it seems enough. Spec directory holds test files (aka. specifications). In main directory there are classes and everything else. It will probably change when project will start getting bigger, but for now it’s good. Lets just take a look at files content:

A simple class and test. It doesn’t get any simpler than that, does it? BTW, if you don’t know how the specifications work – take a look at Jasmine tutorial – it’s all pretty easy and nice.

How do I run those tests? Well, Jasmine says that I should create test running html file and include required scripts in there. Simple, sure, but – boooring. Who likes going to the browser to see if test are passing? No – I wanted to be able to run them from command line. In future this will make it easy to include them in some Continuous Integration and what else. Jasmine-node comes to help! It allows running Jasmine specifications using nodeJs. Exactly what I was looking for.
So I installed it:
npm install -g jasmine-node
and tried running the tests:
jasmine-node --coffee ./spec
--coffee parameter indicates that specifications are written using CoffeeScript, second parameter is simply path to directory containing specifications that needs to be run. After spending some time fighting with this tool (there is a bug that suppresses any error messages when running under nodeJs 0.10 so it wasn’t notifying me on compilation errors – workaround – try first compiling spec.coffee files manually if you see that jasmine-node quit with no error or output at all) it run my tests. And they failed.
Reason for this is pretty obvious – there is no reference for Ball class in specification. In C# we would need to add using statement, but what about CoffeeScript/JavaScript? There is no easy way to do this. It assumes that you will include all required files onto web page (or squash them into one file and include this file). Even then it would not work correctly – Ball would be defined in different block of code and would not be visible outside of it.
CoffeeScirpt proposes attaching the class to some global variable (like window) or exporting it using nodeJs exporting mechanism. First solution will work when running in browser. Second when in nodeJs context. But I want both – tests in nodeJs and normal code in browser!

In this case there is no other way but to decide on runtime which export mechanism is to be used. And since JavaScript is dynamic language it’s very easy to achieve. Just decide which variable is present and use that one as export point.
root = exports ? this
root.Ball = Ball

? is CoffeeScript existing operator – it checks if variable is defined (i.e. is not undefined and not null) and returns that variable if defined. If variable does not exist – it returns statement on the right. this is object which is used to create class definition – in browser it will be window instance – who would’ve guessed? In second line we assign our class to property on exporting point – how I love dynamic languages!

OK, exporting is covered. But how to import this in specifications? It’s simple since we assume our specifications will be run only from nodeJs – then we can use require method and get what we want. Below is final code:

Require returns exports object. To this object we have attached our Ball class and now we can retrieve it and use it in our code. Re-running jasmine-node tool proves that everything is OK now – test passes. Problem solved!

What’s left? Well – it won’t work if we will try using normal jasmine html runner. But I think I have an idea on how to solve this as well – with a little hack, but it should be fine, I hope. We will see how it turned out in next blog post. Take care!

Self closing script tag

While I’m having fun with CoffeeScript those last few days, to try it out I’m creating plain old HTML pages sometimes. Just a simple, messy html to see how script behaves in browser. Of course to do that script must be either part of html file itself or included into it using script tag. Simple enough, done that like hundred times over the last few years.

But apparently doing something many times does not mean you will do it correctly next time. Or you will know how to do it correctly. An hour ago I would not be able to tell what’s wrong with this file:

Seems correct, doesn’t it? All tags closed, all tags present. Sure – that’s not the nicest html you will see, but should do the job. Yet, there is small, but serious issue that will cause JavaScript code not to be executed. It’s the self closing script tag.
This StackOverflow discussion gives detailed answer to the problem: Why don’t self-closing script tags work?.
But just to sum it up – you will either need to explicitly mark that your document’s MIME type is application/xhtml+xml or use explicit closing in script tag. This is because browsers interpret tags in some way that causes them to generate content different than expected. For example, the above code could end up with html looking like:

The alert is out of the script section, causing it to be interpreted as normal html which is rubbish.

So this was a good day – learnt something new. Hope you learnt something too!

Starting with CoffeeScript

So the time has come for me to look into something interesting and not work related. I should have done this long time ago, stupid me. At work (yea, I lied saying it won’t be work related) recently I’m coding in system specific scripting language. Or should I say “scripting” language. Basically it is subset of C with some built-in functionalities for financial systems. I’m pretty new to this but I’ve already noticed that coding some small scripts in C is not the most pleasant experience. Nor it is efficient. Creating forward declaration of functions, declaring variables at the beginning of block, remembering all different types and managing memory – it’s boring and time consuming when all i want to do is calculate some things, check few conditions and maybe send an e-mail. This got me thinking – what scripting language would be better for such task? And that’s how I realized I don’t really know any such language at all.
Of course I’ve done few things in JavaScript but it was nothing really fancy, just small snippets using jQuery to make pages more fancy and maybe do some Ajaxing. Nothing more.
I’ve heard about Perl, Ruby and probably few other such languages, but I’ve never coded single line of code in them. This made me angry on myself – why didn’t I? It’s always good to know how something can be done in different language, get a fresh look and maybe touch a new paradigm. And I was wasting such great opportunity to learn new stuff. Not for long, I said to myself.

First I tried Ruby since it was getting a lot of buzz last few years (and even Jeff Atwood uses it – Why Ruby?). So I started reading, trying some things out (it even proven useful as quick and simple way to solve small problem in everyday life). But I would need to learn about Rails platform and other stuff to build something for the web – which I think is simplest way to share your work with the world. Sure, I could learn it – and will in future – but now I didn’t feel like it. So I remembered that there was something like CoffeeScript – language that compiles into JavaScript. Given I know a little of JS and want to build for web – it was decided.

To start with CoffeeScript one needs first to install it. I’ve picked the easiest way – first install NodeJS and then, using simple command install CoffeeScript:
npm install -g coffee-scirpt
This way we will have compiler available globally – everything exactly as coffeescript.org states. Easy way to verify if everything is OK is to write some code! But why bother with files for easy checks. CoffeScript compiler allows us to pass code as a command line parameter, so lets use this feature.

With a quick look into help (coffee -h) we see that passed parameters say to generate output code to console, pick a code from command line parameter and for easier reading – do not generate top-level function over the generated code (this function normally serves as outer block limiting variables lifetime and helping avoiding overwriting variables from other modules).
Exact code meaning is pretty simple – display alert for each number in array – syntax is simple and easy to understand. Generated code also seems pretty neat. That’s exactly what I was looking for – nice code compiled to nice output that can be easily used on the web.

So we can code, but we also need to make sure that the code works. We can of course check manually if the JavaScript works using any modern browser, but that’s no fun. Unit tests are fun – so we will have a look on how to write some of those for CoffeeScript. I’ve decided to use Jasmine testing framework, which also supports writing tests in CoffeeScripts. We will have a look how it works in next blog.