I recently had the honor of one of my minor changes to the Jasmine-Node project being merged into the project master branch. I added a new option to the command line used to invoke the Jasmine-Node tests. Using a --configure option followed by two additional entries will add a variable to the process.env in the invoked node process. Adding this feature allowed me to move my tests with my node server through it's path from testing to production.
As a "front-end" developer, I have very little access to the machines my Node server runs on. By no means is that a complaint; I understand why the server team wouldn't want me to mess with their environment. It is beyond the scope of my current role to touch any servers in order to support an application specific JavaScript server which is being managed by IIS. I needed a way to be able to move my tests with the server from development to staging to production. Moving my tests with the server allows me to confirm that it is working correctly on each server environment. A quick invocation of my tests, and I have a strong validation that the server will work as expected in its new home.
Invoking Jasmine-Node is done through batch files that I run manually, and will eventually be called by a build process. It is pointless to have the test use the same network resources in all environments. The point is to confirm its functionality within each server instance's context. Adding a command line switch means the only thing that needs to be different between each instance is it's batch file. The batch file is something I have complete control over.
Using the command line option is straight forward:
When Jasmine-Node runs the tests the key-value pair will be accessible through the process.env object:
Using this flag to make server names dynamic is only one possibility. The flag could be used to set timeout duration, file and network paths, and a host of other possibilities. The result is a Jasmine-Node suite that can be portable or turned into a template for other similar projects.