What's the difference between your application's javascript code and its java/ruby/python/whatever code?

Think about it for a second. Done? Well, the answer is: none!

In today's web applications your javascript code is no different from the rest of your code base but yet we treat it with disregard - and we're all to blame.

We often see developers investing time writing all sorts of automated tests around their code base but fail to do the same for their javascript - and yet they get surprised when their client can't click on a button on their web app that depends on that ajax call that has been manually tested once when the page was first released.

Ask yourself this question if you're not sure if you should be testing your javascript: If it breaks, can my users still benefit from my app? - I think the answer for most web apps is obvious.

As for tools, I can only speak of two, JsTestDriver and screw-unit, the latter being the one we're using in my current project at ThoughtWorks.

What I liked about screw-unit is that it's very easy to get it up and running. Being a Behavior-Driven Testing Framework it's not surprising it has a syntax similar to Rspec -which I prefer over JsTestDriver's similarity to JUnit's.

This is how a test written with screw-unit could look like:

Not too bad for a javascript test suite huh?

So the next time you write a javascript line of code, how about writing a test for it? Consider using screw-unit as your tool but if you have been writing tests using a different framework and you're happy with it, share your experience.
I'm always keen to learn better ways of doing what I do.

Cheers!

The rcov_plugin project is a rails plugin for rcov that adds some useful rake tasks to your application.  And since I'm currently working in a JRuby project it made sense to use this plugin.

The thing is, among other stuff, an rcov report from a JRuby project includes some files that shouldn't be there at all, plus you also need to change the way you call rcov as such. Thus, I thought I'd contribute these changes to the plugin and my pull request was approved this morning - just install the latest version and you should be good to go.

It was useful for us here, hope it might be useful for you too.

Enjoy :)

When testing it's pretty common to see the need for mocking a certain object, say, a Data Access Ojbect. This way you don't need to depend on a database and you can focus on the actual logic implemented by the method being tested.

For that you have several alternatives like creating the Mock class by hand or - and this is the more common - use one of the various mocking libraries out there.

They all look the same but the past couple of days I've come accross to a new - at least for me - mocking library for Java. It's called Mockito. As the creators state, technically, Mockito is a fork of EasyMock.

I have used EasyMock already but I do think Mockito has its advantages. I find it clear and a bit less verbose to write.

From one of the stubbing examples on their website:

//You can mock concrete classes, not only interfaces
LinkedList mockedList = mock(LinkedList.class);

//stubbing - before execution
stub(mockedList.get(0)).toReturn("first");

//following prints "first"
System.out.println(mockedList.get(0));

//following prints "null" because get(999) was not stubbed
System.out.println(mockedList.get(999));

Looking forward to using it in production! ;)

I never paid too much attention on testing database stuff. While working with java, the closest I got to something workable was using the test case abstractions provided by the Spring framework. It ensures that each test method runs in its own transaction that is rolled back after the test's execution.

Fair enough. I used the setUp() method on my TestCase to configure some records so I could work with them, removing all of them in the tearDown() method. It was quite simple and worked.

But I always felt something strange with this solution. First of all, I had to add another framework just for that. - Actually I was using spring for dependency injection, but if I wasn't, it wouldn't be a nice option. And another thing that bothered me, is that you cannot guarantee that your database is in a known state.

After I started to work with Ruby - and Rails - I discovered the testing fixtures. It is a really nice way to set up your testing data without having to worry about your database state. - If you don't know what I'm talking about, follow the above link first.

Then I received a message from a co-worker saying he was having some trouble in using DBUnit with Hibernate, and asked for some help. I've heard of DBUnit before but never tried it myself. It was a very good opportunity to take a better look into it.

The basic idea after all is very similar to that of the Rails Fixtures: You have some sort of external file - XML in this case - where you set up the testing data. So the framework takes care of erasing the database, inserting your test data and returning it to its original state.

So far so good, DBUnit's default Classes works with JDBC, DataSources and JNDIDatasources, but not with Hibernate. The effort to put them working together is minimal and is documented in their web site.

I decided to share how this can be done with hibernate and in the end, you would have a test case similar to this one: