Integration tests written in .Net using locally hosted node.js server

I've blogged before about hosting web services created with Web API inside a test fixture in .Net, what follows is the same idea but in this case hosting a node.js implemented web service, this is using the node.js server I created in this previous post.

Jumping straight to the solution this is what I came up with:

As you can I've managed to reduce the amount required to be specified for each test fixture to 3 parameters:

1. working directory for node.js server,
2. full path to the node executable, 
3. node server name and any arguments (note the port number).

The implementation detail has been pushed into the base class - WebServiceIntegrationFixtureBase.

Before showing the implementation for this class, the test runner & fiddler outputs are shown below:

The base class implementation is shown below, as you can probably guess this uses the Process class from the System.Diagnostics namespace:

Loading ....

As you can see there isn't much going on, the main thing to notice is the use of an event handler for the Process class Exited event. This is done to check if the process starts up and remains running. The node server will return an exit code '8' if it fails to start the server correctly. The most likely reason this will happen is because the port the derived test fixture is using is already in use by another process, and if this happens I want to fail the test.

You might ask why bother?

I run my test using a continuous testing plugin like nCrunch and it's configured to run test simultaneously. This means if I'm not careful about the port I specify for each test they may clash and cause node to crash on start-up - in the example above I'm not worrying about this as there is only one test, but if there were multiple tests in the fixture I would be using some mechanism to generate a unique valid port number.

Read More

Building mock web service in node.js instead of Web API

I needed to build a mock back-end web service this week because the middle-ware team wasn't ready (they're useless standard Java 'enterprise' developers) and @Jason challenged me to write it in node.js. He showed me an example of how this was done before and said it shouldn't take more than 5 minutes to have something up and running, I've done this kind of requirement previously in Web API and thought it would be interesting to finally do 'something' in node.

All coding contexts have been changed to protect the innocents :)

The requirement was for a web service returning JSON defined resources and the idea was to map the request URL to the local the file system, where the actual content to be returned is contained in a *.json file and the actual file-name represent the HTTP code to be returned, some examples are show below:

'http://localhost:1008/examples/user/1' maps to 'd:\work\node\resources\user\1\200.json'

'http://localhost:1008/examples/user/2' maps to 'd:\work\node\resources\user\2\404.json'

'http://localhost:1008/examples/user/3' maps to 'd:\work\node\resources\user\3\302.json'

So the above example User '1' maps onto a valid response (200 HTTP code) and returns a User JSON object contained in the 200.json file, user '2' maps onto a unknown resource (404 HTTP code) and will return the message contained in the 404.json file and finally user '3' cause a URL redirect to another User resource as defined in the 302 file.

This could very easily be done using Web API or node.js, either implementations allow me to dynamically add resources as I require - I can modify the types & number of the resources without having to recompile & restart anything for the new resources to work. Having built mock service in Web API before I was interested to find out how much & how quick it would be to build it with node.

First, download and install node from here, I went for the standard install using the MSI installer:

Second, download Web Storm evaluation version from here, I decided to try out Web Storm and esque my usual choice of Visual Studio:

After going with the standard install node needs to be configured in Web Storm. This can be done by going to File -> Default Settings and selecting 'node' - and installed the pre-requisties and configure the executable path for the node executable:

Once configured ready to do some node development:)

I created an emtpy project and add a 'server.js' file:

Next was to configure debugging to use node, this is simple, just selected the node configuration and add the 'server.js' to application server path:

The project is ready to go, okay it does nothing, but I can at least start the debugger and see the output in the Web Storm console window:

I used express.js to handle the HTTP requests & responses and node-fs to access the local file system. These are 'added' using node package manager - this is similar to nuGet, except that it is more mature and reliable IMO. These and other modules are referenced in the 'server.js' file as 'require' statements, you can see this in the following screenshot:

Loading ....

Hopefully what should be obvious from the above, there are two handlers for HTTP requests, one is for resources under the 'examples' sub path and the other is a wildcard for everything else which will return a 404 HTTP code. The other thing to note is the use of the options module, this is for parsing command line parameters and this give the ability to specify a port for HTTP server (defaults to port 1008 if not specified).

The service is going to map HTTP requests to file system locations, the project viewer in Web Storm give a good idea of what I mean, the screenshot below shows the file structure of not only the javascript files but also the mock resources I'm going to use:

The resource is going to be a 'User', and as you can see there will be three available, id = 7, id =8 & id = 9. Each will return a different HTTP code and possible data as described:

    Id = 7 - this will return HTTP code 200, with the contents (json) of the 200.json file,

    Id = 8 - this will return HTTP code 404, with the content (message) of the 404.json file,

    Id = 9 - this will return HTTP code 302, with the header (location) of the 302.json file,

So this pattern allows me to mock out any response scenario from the service - any HTTP code can be mocked.

The other thing to note about the above screenshot is the 'statusCodes.js' file - this is a locally defined npm module. It's responiblity is to dynamically load the other local modules in the 'status_code_handlers' folder, these modules provide the specific logic for full-filling a HTTP code, e.g. the '200.js' file is shown below:

The completed 'server.js' file looks like this:

Loading ....

Running the server up I get the following responses in Fiddler:

Requesting User resource Id = 7 return a 200 code with the specific data (json):

Requesting User resource for Id = 8 returns a 404 with the specific error message:

Requesting User resource for Id = 9 redirects to User Resource Id = 7, hence the two requests seen in Fiddler:

That pretty much covers it, it's been a much quicker refactoring loop using Web Storm and node instead of Visual Studio and Web API - Web Storm is a much more responsive development environment, quicker to load, quicker to start a debugger etc...

The code is available for download:

Read More

Suspending & resuming property notifications when using INotifyPropertyChanged

Currently I'm working with some UI code which has a 'domino effect' when a property changes on a view model - the data is being rendered in a tree view, and the reason for the 'domino effect' is because the value of a node in the tree view is an aggregation of multiple child nodes (leaf nodes hold the actual values which are aggregated up). The dataset is dynamic, it can be updated during it's visualization and when this happens we want the ability suspend NPC events being fired until recalculating all the aggregates has completed.

I have the following base class for all bind-able (view model) classes:

What I wanted was the ability to prevent suspend the firing of the PropertyChanged event and then resume later, I wanted to do this via a single new method exposed on this class and the return type would IDisposable and importantly it should reference count when called multiple times without being disposed. I wanted the ability to do something similar to the following test - where I can have nested calls to suspend but it will only resume when the underlying reference count returns to zero:

Loading ....

The User class is shown below:

Loading ....

I wanted minimal changes to the Bindable class - I wanted to avoid increasing the memory foot print of class as much as possible as well as only adding a single public method to the class. Ideally I wanted the Bindable class to have no knowledge directly of the reference counting going on when nested calls to SuspendNotifications method are made.

I came up with the following changes to the Bindable class:

As you can see the only change to the public signature is the addition of the SuspendNotifications method and the internal structure now has a reference to a disposable instance. The RaisePropertyChanged method has been modified to check whether notification have been suspended - if they have then it is added to the instance of the SuspendedNotification class:

Loading ....

The SuspendNotifications method is defined as follows, as you can see there isn't much to the method, you're probably wondering - 'when does the created instance of SuspendedNotifcations get disposed?'

Loading ....

The answer is when the internal reference counter of the SuspendedNotifications class returns to zero.

Looking at the method above what you notice is the returned IDisposable is not the instance of the SuspendedNotification class but the one returned by the call to the AddRef method. Every time the IDisposable returned by the AddRef method is disposed the reference count on the instance of SuspendedNotifications is decremented, once this returns to zero the property changed events are fired for all the properties which have changed whilst notifications have been suspended.

This is all achieved by the parameter passed to the SuspendedNotifications class - basically I've inverted the responsibility for when the SuspendedNotifications instance is disposed, the instance disposes of it's self when the reference count returns to zero. This can be seen in the SuspendedNotifiication class below:

Loading ....

And this produces a successful test output:

Read More