Category Archives: JavaScript

Posts containing JavaScript code

A canonical web test in NodeJS

Working with web applications in NodeJS is great. Using the same language and libraries on the client and server simplified the thinking. And NodeJS has fast tests and restart for a super quick edit-verify cycle when you’re coding.

I like to write tests to verify the server-side and client-side logic, but do you know that the whole solution really is working? You can of course test your service manually after deploying, but that becomes tedious. By using Selenium, we can test that the solution works end-to-end.

In this article, I show how to write a Mocha test that:

  1. Starts up the Selenium test runner
  2. Creates a browser client that can access the application (using PhantomJS)
  3. Starts up the server and sends the browser to the server (running in ExpressJS)
  4. Clicks a button in the web page that triggers some JavaScript (written in jQuery in this example)
  5. Verifies that the call to the server returns and displays correct data

This test can be run with a simple command after you check out the code and requires no setup on the developers computer!

This test starts a new server and client for each test. When using this for real, you really want to make sure you only start the server and the web driver once as these are expensive operations.

The test case of “it clicks menu item” has a lot of callbacks. There are versions of webdriver APIs for NodeJS which are based on promises that you may enjoy using more.

Implementation details

The full application can be found on Github. To implement it, I used the following NPM modules:

  • phantomjs
  • selenium-standalone
  • webdriverjs
  • expressjs (of course)
  • mocha and chai (of course)

Starting the server looks like this:

And the app.js file looks like this:

I have a server.js file which starts up the express application to run normal (outside the tests).

A simplified version of starting Selenium and WebDriver looks like this:

I found that Selenium and PhantomJS has some issues, at least on Windows, so my final code needed a few hacks to work. See the full details at github.


A web end to end integration test in NodeJS requires a little bit of shaking your fist at the heavens to get to work the first time, not in the least due to the need to work around limitations in Selenium and PhantomJS. But once you got it up and running, you can easily test not only that your logic works, but that your whole application works together.

When making these tests, I allowed for a little flexibility as well: By setting environment variables, the same tests can be run with a manually deployed server, so you can use it to verify that your staging server is up and running (for example). And of course, you can replace PhantomJS as a web browser with Firefox or Chrome and see the tests run for real in your browser.

Automate the end-to-end tests of your NodeJS applications!

Posted in Code, English, JavaScript, Software Development | Leave a comment

Horizontal reuse in JavaScript and C#

In his article Horizontal Reuse: An Alternative to Inheritance Toby Inkster compares how to implement multiple inheritance or mixins in Java, Perl, PHP and Ruby. It’s a very interesting comparison of programming languages features and well worth the read.

Toby writes:

In class-based object-oriented programming, when there are classes that appear to share some functionality, this is often a time when people will refactor them into two subclasses of a common base class, avoiding repetition.

Toby gives an example of a Tractor class and a Horse class which can both pull_plough to help on the farm.

However, Horse already inherits from Animal, and Tractor already inherits from Vehicle. […] So ruling out multiple inheritance, what other possibilities do we have?

In this blog-post, I would like to extend (mixin?) Toby’s examples with two of my favorite languages: JavaScript and C#.


JavaScript doesn’t implement classical object-oriented classes, but instead uses prototypes. JavaScript doesn’t have a built-in mixin concept available, but the flexibility of the languages makes it easy for us to create one from scratch:

These mixins acts just as Ruby’s mixins, but like much of JavaScript, it falls on us to create the mechanism for reuse ourselves. There are many libraries out there that aim to do just this, but it’s useful to understand the underlying code.

Just like with Ruby, if we added the Hitchable mixin to Horse and forgot to implement go, JavaScript would only warn us when we tried to call horse.pull_plough().


C# offers extension methods which aim to do the same thing as defender methods in Java, but rather than having to add the methods to the interface, C# allows us to put the extension methods in an independent static class.

Just like Toby’s Perl example, all the important qualities of horizontal reuse are covered, but very differently from the Perl example: We have a name for the common behavior, the Hitchable class specifies what’s needed to make something pull a plough (the IGo interface) and we get an error message from the compiler if we try to PullPlough on something that doesn’t implement IGo.

The difference is that the compiler has no idea that we may want to make Horse Hitchable before we try to call MyHorse.PullPlough().

The C# approach has one big advantage: Anyone can create the Hitchable static class. Neither Vehicle, IGo or Horse needs to know about it’s existence.

The flip-side of this is that the only type that we can assign both Horses and Tractors to is the IGo interface.


Different languages offer different mechanisms for horizontal reuse. JavaScript reminds a lot of Ruby, but requires more manual work for the developer. C# has a totally different approach from other languages that offers some unique strengths, but also has limitations compared to the Perl and PHP approaches.

Make sure that you check out Toby Inkster’s article for four other languages each with their unique approach: Java, Ruby, PHP and Perl.

As developers in one programming language, it is useful to know what solutions are offered in other programming languages for the same problems that we face ourselves. For programming language designers, we live in a golden age with lots of different ideas that I hope may cross-pollinate between modern programming languages.

Posted in C#, Code, English, JavaScript | Leave a comment