The techniques here are dependent on some libraries, but this should already be included if you are using the phantomjs-qunit-runner maven plugin. Credit to this article to for the DOM setup and teardown helper functions.
Alright, onward to the code examples!
Suppose we had a javascript function that does a simple DOM manipulation to add some text to a given element as such.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
JSDEMO.quickstart=function(){/**
* Public interface
* @scope JSDEMO.quickstart
*/return{/**
* Appends some text to an input element ...
* @param addToElement Element to append some text to
*/
appendChildNodeToDom :function(addToElement){var newnode = document.createTextNode('Here is some content.');
document.getElementById(addToElement).appendChild(newnode);}};}();
Here is the code to test it! Pretty simple really.. comments inline
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
test("Can append child to element in DOM",function(){// expected results for the test to compare againstvar expectedTestDivHtml ="Here is some content.";// Helper function to set up DOM element to test with
DOMSetup('<div id="testDiv"/>');// Call our function to be tested with the DOM element created by the helper above
JSDEMO.quickstart.appendChildNodeToDom('testDiv');// Test! See if results is as expected
equal(expectedTestDivHtml, $('#testDiv').html());// Helper function to tear down DOM element tested with
DOMTearDown('#testDiv');});
January 6, 2012 at 12:26 pm | Blog, Development | No comment
nide is an open source web-based IDE for node.js. It’s designed with simplicity and ease-of-use in mind. nide was originally developed as part of the Node Knockout 48 hour coding competition.
Current Features of nide includes:
Project tree display
File operations (create/delete/rename files and folders, hide/show hidden files)
Syntax highlighted code editing
OS X Lion-style automatic save
OS X Lion-style version management with revert and side-by-side editing features
Real time project tree filtering (using regular expressions)
NPM integration (display currently installed packages, add/remove packages)
On top of that, check out ‘The Interface’ tab on the nide site. They’ve managed to create a very nice mouseover effect to put each feature into focus without cluttering the screen.. very nice indeed!
Since the 2008 financial crisis, enacted regulations mandates an entirely different approach to risk analysis. This means that the old systems, which relied on overnight batch risk calculations and predefined queries, can no longer suffice, and a more real time approach to risk calculation, with on-the-fly queries, is needed.
From a solution architecture point of view, Risk Analysis is a compute-intensive and a data-intensive process. Looking at our customers’ systems, we see ever-increasing volumes (number of calculated positions and assets, number of re-calculations, data affinity, etc.) and on the other hand we see an ever-increasing demand to reduce the response time, to conform with the regulations or for competitive edge. That makes it a classic Big Data analytics problem.
Have a look at the webcast for some great insight. Highly recommended for IT professionals in the Financial Services industry
January 1, 2012 at 10:48 pm | Blog, Development | No comment
Renowned JavaScript Guru Addy Osmani has a great presentation on how to handle JavaScript on large projects (defined as >100K LOC)
Today’s solutions and frameworks are great, but how do you keep them under control as your project grows?
In this presentation, Addy Osmani presents an effective set of design patterns for large-scale JavaScript (and jQuery) application architecture that have previously been used at both AOL and Yahoo amongst others.
You’ll learn how to keep your application logic truly decoupled, build modules that can exist on their own or be dropped into other projects and future-proof your code in case you need to switch to a different DOM library in the future.
The typical workflow of a Continous Integration/Continuous Deployment process is fairly well understood. As a quick recap, code is checked out regularly, then built, and following that a whole suite of tests are run to confirm that the code changes did in fact fulfill its purpose and did not unintentially cause other parts of the app to misbehave.
In web applications, it is becoming increasingly popular (as it should be) to have the application deployed to a container (eg, using Cargo) so that automated UI tests can be run via Selenium or Watir or QTP or what have you.
Problem
The deployment step is often asynchronous (ie. it does not wait until complete before it returns). Since your automated UI tests should only run once your app is deployed to the container and has started, how do you ensure that is the case?
This Maven plugin is designed to be used in a continuous deployment scenario where the command to deploy an application to an app server is asynchronous.
This Maven plugin will poll a given url for a specified period (while blocking) until it times out, or gets an expected response (yay, deploy complete!).
In this example, it will poll www.google.com for the HTTP status code 200 (OK). If it does not receive the expected response, it will wait for 10 seconds and then try again up to 5 times in total.
As a handy tip, when several plugins are configured to the same phase in a maven lifecycle, they are executed in the order in which they are declared in the pom.xml. This is true in Maven 3.0.3 and later.
LinkedIn has an interesting approach to Continuous Integration in their mobile app. Of special interest are the ‘Fixture tests’ which mock HTTP/AJAX requests, and the ‘Layout tests’ which does a visual comparison against baseline! Would be very interesting to try and integrate the Layout tests into my automated builds..
Our mobile CI consists of a five stage pipeline:
Unit tests: run in less than 10 seconds to test individual modules/units
Fixtures tests: test solely the client apps by having them use static/mock data
Layout tests: test the appearance of the client apps by taking screenshots and comparing them against baseline images
Deployment: automatically deploy to a staging environment
End-to-end tests: run end-to-end tests against the staging environment
I’d suggest following the LinkedIn Engineering blog as they often have very interesting articles about their approaches to solving problems.
Also, their approach to bug prediction is a very interesting. Basically they, devised an algorithm that predicts which source files are due to have a bug introduced based on various metrics. This algorithm then pops up a note in their code review tool so that the review can be handed off to a more experienced reviewer.
QUnit tests are great, but they only run in my browser locally. I want to be able to run these tests locally while developing yet still be able to hand those tests off for automated testing by Maven when my build is run..
When presented with this problem several weeks ago, naturally I turned to the web for existing solutions but could not find one! The closest I came to finding a published solution was at http://whileonefork.blogspot.com/2011/07/javascript-unit-tests-with-qunit-ant.html where the writer talks about an Ant solution.
What to do? Write a Maven plugin and share, of course!
Solution outline :
QUnit needs to run in a browser. Instead of choosing something like RhinoJs which provides only a JavasScript engine, I selected PhantomJs instead. PhantomJS is a headless WebKit with JavaScript API. It has fast and native support for various web standards: DOM handling, CSS selector, JSON, Canvas, and SVG.
I then needed to capture the output of the test results on QUnit was finished running. Luckily, the QUnit framework provided handy callback functions that made this easy. Also, props to Rod for getting me started.
What was left was only to write the Maven plugin which ties the source JavaScript file to be tested, the JavaScript/QUnit test file and PhantomJs altogether so the Maven lifecycle magic could happen!
Then, place your JavaScript file to be tested (hereafter referred to as JavaScript source) in a location in your Maven project, in this example it is src/main/js.
Next, place your JavaScript/QUnit test files (hereafter referred to as JavaScript tests) in another location in your Maven project as per Maven convention. In this example, it is src/test/js.
This plugin works by convention. Given a JavaScript test file called FooTest.js, the plugin will run PhantomJs, load up QUnit, load up Foo.js, then run the defined tests. The results are then handled accordingly.
Finally, let’s see the magic happen! The plugin is tied to the Maven test lifecycle.
mvn test
produces the following result
Success! .. well.. it’s a build failure, but that is the point as I deliberately had a test failure
Another nice feature is that it generates the HTML QUnit wrappers you would normally use when using QUnit. This should make development work even easier by being able to run your tests locally in your browser. Look in the Maven target/qunit-html folder.
Next step : Make the test output JUnit xml compliant (currently untested), make the option to load up other JavaScript files (eg containing helper functions definitions used in your JavaScript) before running the tests.
Skipfish is a great and FAST automated pen test tool with a low barrier to entry by Google’s own web security expert Michal Zalewski.
Skipfish is distributed as source only at http://code.google.com/p/skipfish/ and I’ve looked around the web for a compiled Windows version but couldn’t find one so I’d thought I would share instructions on how to build Skipfish on Windows in Cygwin.
I hope to provide a Windows executable that I will keep up to date as releases roll out.
Go through standard the Install Wizard steps until the ‘Cygwin Setup – Select Packages’ screen. Select the following additional packages & install the following. ‘devel’ versions if available
