There seems to be two possible reasons. Streams and Sockets.

I have no problems with PHP 5.3.0. It works.

PHP 5.3.3 BROKEN IMHO.

I got tired of switching between tabs and firebug when trying to figure out what the hell was going on with my ajax requests.

The worst is when I tried finding anything about my requests in Internet Explorer. Forget it!

So I wrote a jQuery Plug-in. You attach it to your page and it will monitor all your Ajax requests [1].

The running unit tests for the source.

The running unit tests validating with jQuery 1.4.2 Ajax tests with the plug in. [2]

Two feature that are becoming a must have for this plug in

1> Mocking Ajax request by specifying your Ajax settings like this: { /*other settings*/ mock: true }

2> What I’m going to call single-shot.

• Fire an AJAX request once
• For all repeat requests will be  mocked with the response data.

Presently the way I TDD a client, is I retrieve content using the normal Ajax call to get the presentation HTML.

Then I make another Ajax call in my normal code and store it into a string. At the start of each test I load this string into my: $(‘#contentContainer’).html(myPreloadedPresentationHTML);

Then remove it. So for all the unit tests I make a total of TWO Ajax calls. That’s one too many calls (latency can be up to 1~2 seconds OUCH!).

Since the monitor already controls the success callback of the original Ajax request why not replace it with my own.

First Ajax request success supplies the response data.
Hang onto it.
Any other calls to this request will get the stored response data.

I would welcome any comments.

Good or Bad!

…even requests.

Please help push against this software. I think it is a great tool and could be better with your help.

[1] Because jQuery 1.4.2 executes the complete callback twice during the request. If you want you can include my modified jQuery 1.4.2 library that fixes this use it. See here for bug tick #5383 .

[2] Two failing tests dealing with preserving the context. It is caused by XPC Cross Origin Wrapper. If anybody has a fix, post on stackoverflow.com.

Thanks from the ajaxMonitor Team.

function NewMessageBus() {
    return {
        when: function(name, fn) {
            this.fire[name] = fn;
        },
        fire: {}
    };
}

var msgBus = NewMessageBus();

Usage of this requires two things:

Creating the event

var presenter = (function() {
    msgBus.when('getContent', function() {
        model.load(view.content);
    });
}());

Note that the presenter is state-less.

Firing the event

var view = {
    getContent: function() {
        msgBus.fire.getContent();
    },
    content(htmlData) {
        $('#contentContainer').html(htmlData);
    }
}

var model = {
    load: function(cb) {
        $.ajax({
            type:       'GET',
            url:        'myContent.php',
            dataType:   'json',
            data:       {/* some parameters */},
            success:    function(data) {
                // some preprocessing of data
                cb(data.html);
                // some post processing of data
        });
    }
}

Usage

view.getContent();

That’s it pretty simple.

The view/model does not have any references to each other.

It is an idea that there are areas that can  be improved.

This is what I’m going to be about it.

Well I can tell you that I prefer comabt training…

Operational programs consist of programming things like data objects, value objects, concrete data types. Major boring shit! Nothing interesting happening here.

Combat training this includes the dynamic portions of the code you write.

Let’s take an example:

You have a web page.  On this web page you have a navigation menu and you have a content container. When a user clicks on a menu item some content will be displayed in the content container via an AJAX request to the server. The content is stored some how on the back-end (database, flat-files, or another server), we don’t really care for this example.

Now where is the combat training and where is the operational programs areas.

It might be better to isolate to two specific areas. Client-side and Server-side.

Server-side

Operational Program

The concrete implementation of the content, the HTML output of the server. The actual data coming out of your back-end

Combat Training

The selection of the types of content to be sent to the client-side. You know images, text, google geolocations, whatever you can imagine.

Client-side

Operational Program

jQuery manipulations, $(‘my_div’).hide(), something along those lines.

Combat Training

When the user selected a menu item did the correct AJAX request go to the server.

So whenever you are TDDing your code, remember you want combat training not operational programs.

Tank quote (Matrix)

What is Mocking?

The funny part is the remark to the question.

when you deride people for not being able to unit test due to dependencies

’nuff said

This is done in (Administer -> Site Configuration -> Performance).

See this post.

• Microsoft Vista
• Netbeans 6.8
• PHP 5.3.2
• Drupal 6.16
• Apache 2.2

Things to get running:

• Netbeans Plug-in
• Drupal
• Webgrind (profiling)

Things to remember:

• Remove in hosts file, the entry ::1
• Restart Apache server when getting the white screen of death
• Have to patch core when installing simpletest
• ereg() php function deprecated

Future:

• find a code coverage tool similar to webgrind

Are they going to blaze with speed?

Or is it April Fools?

Chocolate Covered Unit-Tests