Freitag, 17. August 2012

JsTestdriver Getting Started


The hello world test project on the JsTestdriver page is no longer where it used to be. Instead, I cloned

git clone http://tddjs.com/code/03-tools-of-the-trade.git

It is the companion website to Christian Johansen's book Javascript Test-Driven JavaScript Development. I found this book very helpful to get me started.

After checkout, you will find a folder jstestdriver in the directory where you have executed git. The conf file in that folder sets up JsTestdriver to use port 4224 and specifies the js files and tests to load:

server: http://localhost:4224

load:
  - src/*.js
  - test/*.js

Copy the JsTestdriver jar from the JsTestdriver downloads page to the jstestdriver folder. Open a commandline to that folder and start the JsTestdriver process using

java -jar JsTestDriver-1.3.4.b.jar --port 4224


The next step is to attach the browser to JsTestdriver, a process called capturing. Open your browser to

http://localhost:4224

Next, hit one of the capture browser links. The browser shows a page which displays some information about the last test execution and the current status in general.
The capturing process can be automated by passing your browser's location. Instead of firefoxpath and chromepath, provide the paths to the browser executables on your system:

java -jar JsTestDriver.jar --port 4224 --browser firefoxpath,chromepath

Once the browser is attached, you can run the tests using

java -jar JsTestDriver-1.3.4.b.jar --tests all

The commandline output shows the test result. All tests should be fine.

We will now cause a failing test. Edit the file

jstestdriver\test\strftime_test.js

and change this test:

TestCase("strftimeTest", {
  setUp: function () {
    this.date = new Date(2009, 9, 2, 22, 14, 45);
  },

  // ...

  "test %Y should return full year": function () {
    var year = Date.formats.Y(this.date);

    assertNumber(year);
    assertEquals(2009, year);
  }
}

so that it asserts a different year instead of 2009. For this, change the line.

assertEquals(2009)

to a different year, maybe 2010. The code under test is:

Date.formats = {
  // ... Formatting methods ...

  Y: function (date) {
        return date.getFullYear();
     }

The resulting output shows the failing test:

Total 5 tests (Passed: 4; Fails: 1; Errors: 0) (2,00 ms)
  Firefox 14.0.1 Windows: Run 5 tests (Passed: 4; Fails: 1; Errors 0) (2,00 ms)
    strftimeTest.test %Y should return full year failed (0,00 ms): AssertError:
expected 2010 but was 2009
      @http://localhost:4224/test/test/strftime_test.js:16


The reason for the failure is that the date has been initialized during the test setup to contain some day in the year 2009, but the test expects 2010, now that we have manipulated the file test\strftime_test.js.

Freitag, 6. August 2010

Adjusting the Spring Webflow swf-booking-portlet-faces for use with Pluto 2.02

Here is what I did to get the spring webflow portlet sample running with Pluto 2.02.

Several tweaks to the war that is provided on the Spring Webflow sample page are necessary:
  • remove com.springsource.javax.el-2.1.0.jar and el-ri-1.0.jar from WEB-INF/lib, a different EL implementation comes with Pluto 2.02, and two EL implementations cause trouble in Tomcats classloader
  • add WEB-INF/classes/../FaceletPortletViewHandler.class from the sample portlet in https://facelets.dev.java.net/files/documents/3448/21118/facelets-portlets.war, it does not come with the com.springsource.com.sun.facelets-1.1.15.jar. Maybe it will be part of newer facelet implementations, in that case you do not need it. This is a solution for the classcast exception saying "org.apache.pluto.container.impl.RenderResponseImpl cannot be cast to javax.servlet.ServletResponse". The reason is that Pluto 2.x, adhering to the Portlet 2.0 spec, now uses implementations of PortletRequest/PortletResponse, which do not extend ServletRequest/ServletResponse. The FaceletViewHandler tries to cast the response from the faces context to a servlet response, the FaceletPortletViewHandler avoids that cast.
    I found the explanation for that problem here http://osdir.com/ml/pluto-user-portals.apache.org/2010-04/msg00016.html and the solution here: http://old.nabble.com/Facelets-in-portlet-td18131659.html
  • edit faces-config.xml to use the FaceletPortletViewHandler instead of FaceletViewHandler
  • exchange jsf-portlet.jar 1.2.3 by current one 1.2.5 from http://jsfportletbridge.dev.java.net (not sure if this is necessary)
Afterwards the portlet ran on my Pluto installation. However, it is not exactly pretty.
The booking sample page does not display properly with the Pluto css, the radio buttons are drawn over the labels. A quick fix which proves that css causes that problem is to adjust /pluto/pluto.css for the label object:
label {
width: 60%;
text-align: right;
margin: 0px 5px 10px 0px;
}