JsUnit

OliBye and ChrisCottee are using Rhino to unit test Java Script.

Rhino is a pure Java, JavaScript engine which we're using from inside JUnit TestCase's

We're looking forward to the refactoring JavaScript since it's a prototypical language.

OliBye is also interested in using JavaScript where Java's strict type checking is annoying, e.g. in polymorphic functions over collections and the like.

We'll update BigBenTools with JavaScript Unit testing idioms as they emerge.

We've also been looking at other ServletTesting stuff.

(This is the story which forms the basis of the article. RealCode will be inserted to illustrate the points, but OliBye is just trying to remember why testing JavaScript was a good idea in the end). OliBye and ChrisCottee had an ActiveX control in a web page that drew a graph. OliBye wrote the code, while he wasn't pairing by copying an example. Neither Chris nor Oli fully understood the control, even after reading the documentation, but the code did what it was supposed to do.

Until what it was supposed to do changed.

Changing the code was a problem as it wasn't nicely refactored, if it was a price graph it was absolute, but if it was a delta graph it wasn't (or something), basically several aspects were littered through the code.

It was hard to refactor, as there were no tests, i.e. how did you know you weren't breaking the use of the graph elsewhere.

How were we going to unittest a ActiveX object with out mocking up a browser. Well we decided that unittesting the ActiveX object wasn't the problem, as if we found bugs in it there wasn't much we could do, we needed to test our code that interacted with the ActiveX object. This would let us RefactorItWithConfidence?.

Idea's for article Title, CantTestWonttest?

We test fragments of JavaScript using the Rhino javaScript engine (from Netscape) which allows you to compile javaScript functions and then run them in your tests. We have only tested a couple of little functions and classes like this and we got stuck with our pages that used ActiveX objects (the simplest thing at the start of the project) but we it was a great relief when we figured out a way to test the scripts at all.

Testing Java script using JsUnit or Rhino: JSunit is some javascript and an HTML page in which you can include fragments of javaScript to be tested. It provides some asserts and a way of calling all of the test functions on your page plus an output of success or failure. Its really strong point is that it runs in a browser so you get to check for compatibility. The weak point is that it doesn't scale nicely like JUnit, it's difficult to envision suites of tests under this framework.

What I did was try to write javascript tests that you could use in Rhino within JUnit or in JSUnit. The standard javascript test in JUnit was structured like this: Tell the rhino engine about the testcase you are in, this allows the assert wrappers to call junit asserts which throw exceptions you can catch in Junit. Read in a file containing javascript wrappers for junit assertions (these are necessary to help with the mapping from javascript types to java types plus it decouples test code from JUnit so you can run in JSunit). Read in a file containing the javascript under test. Read in the test. Execute the test. Thing I liked about this was setting up the junit side of it becomes mechanical. All of the effort goes into test javascript, where it should be.

The interesting bit was the form of the test code. To make a fake activeX object you just declare something with the same bit of interface you are testing (this encourages you to Demeterise because you don'd want to fake something complicated). You set its methods to count how many times they are called and return example values. It turns out its easiest to test if you use classes a lot rather than functions because then you can change which methods are called in the test. For instance if you have a class TestTarget? and you want to test method A which in turn calls methods B and C .Well in the test you instantiate TestTarget? and change methods B and C to dummy methods which just check they have been called. You don't even need to get their signatures right. The risk with this is that methods B and C don't actually exist on TestTarget? but your test still passes. So I think you need to include a test to check the interface to TestTarget? is correct; this is a test you get for free with typed languages. I found that when I started writing tests for java after doing some javascript tests I would get irritated that I couldn't just change methods to mock methods in the test...

Here's a Unit Testing framework for JavaScript inside the browser (it's basically a port of JUnit):

http://www.jsunit.net

- EdwardHieatt?