Testing javascript with Play Framework 2.0 and JsTestDriver

At qwallet we're building an extensive javascript application backed up by a Scala on Play 2.0 backend. Since I'm using IntelliJ IDEA for the scala development, I'm using it for javascript as well. The nice bonus that comes with that is IntelliJ's integration with JsTestDriver.
While working on the javascript app I have it constantly tested on three captured browsers:

The test console shows the test results (super fast) and any console output that got fetched from the browser, e.g:

In the above test example you can see all tests are passing on firefox and chrome, but fail on safari. The sample has three test cases, the expanded one has two test methods. If there's an error, the stack trace is clickable and intellij will take you right to the line of the error. The tests are pretty fast, 6ms on chrome for this small subset means there's some room to grow.
The extra sweetness of Play2.0 is the auto compilation of javascript files. In dev mode the JsTestDriver is serving the library files and test cases to the browser and the application files are served through the Play2.0 application. Play will recompile the files as it detects change. It gives an extra coverage as in many cases the compiler catches things that I may have missed when writing the test.

On CI mode there is no need to pipe the javascript files through play as the files are compiled once. Not that its much faster this way, but it reduces the need of having play running in the background. As we're going to have qwallet operating in Continuous Deployment mode, testing all parts of the application is crucial. JsTestDriver bundled with the closure compiler provides a nice component in the testing strategy with its fast dev mode unit testing.

BTW, we're hiring. If you're interested, shoot us an email to jobs@qwallet.

Throw undeclared checked exception in Java, take II

Wrapping is in many times a necessity as you may not be able to throw a declared exception for contract restrictions or want to reduce boiler plate code. Wrapping an exception with a RuntimeException is sub optimal, takes more resources and clutter the logs with unnecessary stack traces, makes you look for the root cause. Loved Alexey's idea about throwing undeclared checked exception in Java. Here is a small twist on that AnyThrow class: Now I can do So the compiler and the reader knows I'm breaking the flow with an exception. The stack trace does not have the AnyThrow in it and the "return null" there is only to trick the compiler.

Testing Guice can init servlets

Sequel to the prev post, binding servlets is not enough. You must make sure that Guice can initiate them. For example, a common error is not binding servlets as singleton, there you get exceptions like

ServletException: Servlets must be bound as singletons. Key[type=my.servlet.FooServlet, annotation=[none]] was not bound in singleton scope.

Here's a way to test for all servlets in Guice context When calling init on the filter it would init all servlets in context.

Testing Guice Servlet bindings

Evan if you work with Servlet (for the record, I hate j2ee) and Jersey you can still enjoy Guice.
Unfortunately its not that evident how to test that the ServletBinder is binding your servlets to the right place. Here is a small Assert class that does that.

Continuous Deployment at kaChing

In my last visit to Israel I visited IBM Research, Outbrain and Answers.com. Over there we discussed kaChing's culture, working methodologies and tools. The talk focused on continuous deployment and lean startup and was based on Pascal's and David's posts at kaChing Eng Blog.
Here is the presentation, using the fantastic Prezi tool.

Continuous Deployment on Prezi