Demo Code

Demo Slides

The demo application is written in Asp.net MVC 2, however, it can be written in anything as long as you have a reference to the jQuery library.  The only example that will give you trouble is the ajax example which requires a database, and a change to the connection string in web.config.

If you have any questions or need any help just let me know.

My initial goal was to display a temporary “Your data has been saved” message, once a specific interval has been reached, the element would go away.  Quickly seeing an opportunity to make this work on a universal level (displaying any element in the DOM temporarily), I decided to write this simple plugin:

(function($) {

$.fn.tempDisplay.defaults = {
    delay: 3000
};

$.fn.tempDisplay = function (options) {

    var settings = $.extend({ }, $.fn.tempDisplay.defaults, options);

    this.each(function () {

        var $this = $(this);

        $this.show("fast");

        setTimeout(function () {
            $this.hide("slow");
        }, settings.delay);

    });

    return this;

};

})(jQuery)

One thing to note about this if you’re not familiar with jQuery plugins, this must come after the jquery include on your page, otherwise the objects do not exist

As you can see, there isn’t much to it.  I have created one option which is the interval the element should delay hiding itself.  There are other options I might want to play with here like the show/hide speed, and the show/hide effect, however, this works for my needs at the moment.

Once you have declared this plugin, you can simply use it like so:

$(function () {

    $(".temp-message").tempDisplay({ delay: 5000 });

});

Remember, this will only work if you register the elements in the page load, as is the case in the above code snippet.

I have only used it for one scenario, and I can envision many more, I may update it if I feel frisky enough to extend the code.  Feel free to copy this code and use it to your hearts desire.  Hope it helps give someone a leg up on their project!

Recently, I encountered a development team that has zero automated unit tests (or any other types of tests for that matter; integration, regression, etc..), I have attempted to bring them around, however, I’m met with serious pushback from the dev leads and other team members who are used to the current system.  When I talk about testing I can see the elders of the team glaze over, and say ‘we’ve tried that’ or ‘we don’t do that here’.  This team manages several legacy applications, each of them are at least medium sized,  business critical applications.  I have to ask myself one question, when changes are made to this legacy codebase, how can they be sure they aren’t destroying other functionality in another subsystem or application?  I couldn’t believe there were still teams that don’t see the benefits of automated test harnesses.

So, what are some of the advantages of implementing automated unit tests?

1. It promotes good design: you will write less code if you follow a development methodology like test-driven development, or behavior-driven development. You only write code that will make your test pass (all green lights are good), which will stop (or at least limit) the YAGNI coding behavior.
2. In a collaborative environment you will have less break-fix issues: By being able to simply open a solution file, update from source control, and run a test harness all within your IDE you can be rest assured that (if your tests are written properly and there is adequate coverage) updates from other developers have not broken any code under test.
3. The obvious, test coverage for simple and complex logic: Ever wonder if that complex shipping algorithm is actually performing the logic you were intending it to run?  Or, are you sure those simple classes and operations are actually working?  You’re sure?
4. If done correctly, the tests can serve as your specifications for features: If you have good user stories with appropriate success criteria, you can write a test for each piece of functionality, which will then automatically serve as a good basis for customer and QA acceptance.

The benefits of a testing framework far out way the up front ROI of actually writing the tests.  You will be surprised how much your quality improves if done correctly.  Convincing you manager and team to get on board seems extremely logical, and in my opinion is a must…especially when you have 0 tests currently.

There are tons of good resources all over the internets that explain how to get started writing unit tests, here are just a few (if you have more, please leave comment…most are .net centric, but there are tons of resources for other frameworks):

• Definition: http://en.wikipedia.org/wiki/Unit_testing
• Test Framework (.net): http://www.nunit.org/index.php
• How (.net): http://msdn.microsoft.com/en-us/magazine/cc163665.aspx
• How (Java): http://www.basilv.com/psd/blog/2006/how-to-write-good-unit-tests