Monday, November 20, 2006

JsUnit caching

Ok, so just turning off caching in IE works and I suspect the same will be true for FireFox. Makes sense when I step back and think about it. But now the troubling thing for me is the lack of coverage tools for JsUnit testing. I guess I can just put in a bunch of pesky alerts and figure out which bits aren't being called. 8)

Friday, November 17, 2006

rant, Rant RANT, RRRRRRANT!

<rant>

This is why I don't post more often. I just get annoyed and frustrated. The last post was so short I just used the horrible editor that is part of blogger. And it didn't encode my <rant> tag. And I was in the compose mode. How hard could that be. That will teach me to use an inferior editor ever again...

</rant>

Posts AND Titles



Blogger just let's me publish a post without a title. I'd really like it to not post if there is no title. Twice was way too many times for this to happen...

No really, post DO need titles

Yesterday, I moaned about issues I had with JsUnit and IE. Today, it's FireFox's turn. Actually, like yesterday, this is just a caching issue. Because JsUnit loads JavaScript files from within JavaScript, it seems to hit some caching issues. For IE, these show up in that updating the JavaScript file that is the test file doesn't actually update the file that is run in JsUnit because the old version is cached. For FireFox, this shows up in that the file that the test file is testing is cached. (That's right, I've actually started doing some JavaScript TDD'ing.)

So in FireFox, the code being tested is cached and only clearing the cache will re-load the code. In IE, the tests themselves are cached and..., but I've beat the horse to death by now.

So, how do people manage to do TDD with JavaScript? Are they actually doing it? Have I gone about it in the wrong way?

Apparently, comments are down...

It's been brougth to my attention that comments aren't working. I just switched over to beta.blogger yesterday and it probably did some bad things. I'm hoping that updating the whole site may do the trick. Posting a new entry is the only way I can think of doing this. So, if you find that this entry has a comment, comments are working. Otherwise, I'm not happy...

Thursday, November 16, 2006

JsUnit, take two!

I'd expect a unit testing tool to allow me to do TDD. No really.

The first thing I noticed is that tests are much faster on IE then there are on FireFox. Ok, I'll do this with IE. Except that IE caches the test file. Which means that TDD thing I'd like to do, it's pointless using IE. So, TDD must be done with FireFox. I'll just have to spawn a new IE every time I need to check that things also work on IE. Surely there's a setting somewhere that I can use to stop the JavaScript loading of resources to NOT cache the resource in IE?

Oh, and the thing I really hate about all this is the fact that a stupid little error can cause major headaches. I get no error messages and no static checking of documents out of eclipse. So, misspelling the directory name where the test gets its library code from? That results in an inability of the test to load with an indication that I should check that the file exist, which it did. <sigh> And forgetting to close the parenthesis on a function call? That's no tests are run (it was the first test). Oh the pain...

Titles are an always food...

So I've got a bit of time on my hands to pursue some nice side (though valuable) projects. The main one involves some JavaScript and I'm painfully aware that I don't have any tests on the code I've written. So, I've gone and downloaded JSUnit which I've used on one other protect.

The first thing I've done is run the TestSuite for JSUnit, which seems like a reasonable thing that should just work. But it fails! Grrr, what is going on here. I've run it in FireFox, so, just for completeness, I run in it IE. Guess what? That's right, it passes. Closer investigation reveals that the setUp and tearDown tests are the two culprits.

Time to dive a bit deeper. First of all, here's the offending code:

// JsUnit setUp/tearDown/test order tests

var aVar=null;
var anotherVar=null;

function setUp() {
aVar="foo";
}

function tearDown() {
anotherVar="bar";
}

function testSetUp() {
assertEquals("foo", aVar);
assertEquals(null, anotherVar);
}

function testTearDown() {
assertEquals("foo", aVar);
assertEquals("bar", anotherVar);
}

It looks fairly reasonable until you realize that these tests are dependent on the order in which they run. No prizes for guessing which order they are run on FireFox. A quick search on Google didn't reveal this as a problem that anyone else has run into, hence this post.

Here, for all its worth, is my fix:

// JsUnit setUp/tearDown/test order tests

var aVar=null;
var anotherVar=null;

var testSetup = true;

function setUp() {
aVar="foo";
}

function tearDown() {
anotherVar="bar";
}

function testOne() {
helper();
}

function testTwo() {
helper();
}

function helper() {
if (testSetup) {
testSetup = false;
setUpTest();
} else {
tearDownTest();
}
}

function setUpTest() {
assertEquals("foo", aVar);
assertEquals(null, anotherVar);
}

function tearDownTest() {
assertEquals("foo", aVar);
assertEquals("bar", anotherVar);
}

While a bit more complicated, these tests don't depend on which order they are run. I've moved the original tests to be assertion functions. Then I've created two simple tests that both call a helper function. The helper function determines when it is called whether it is the first or second invocation and calls the appropriate assertion function with the right assertions.

What's this all mean

  1. If you ship code with test, please make sure the tests pass. (In all fairness, FireFox may have changed since this was released more than two years ago).

  2. Your tests really shouldn't ever ever ever ever rely on the order they are run. I don't care what you think, they shouldn't. Each test should be able to run independently and be valid. My modified tests do this, though to get the full intent of the test, both tests need to be run.


Now, back to my regularly unscheduled development...