Natural Order Development

Last night 2 months of poking at my computer almost every evening ended with a room of 30 software professionals looking like the proverbial deer in the head lights. To be honest I was very concerned that I was being too basic and people would demand more in-depth details. I had a Linux build server all set up with source code repository, Hudson build services, a micro-development environment, and a handful of example projects ready to jump into once the questions / demands for details started.

This section deals with tricks and techniques used to effectively test applications and services.

Basic testing patterns are important. But it is also important to properly plan the testing. Building a matrix really helps make sure you are covering all the basis.

A simple case is something that will compare two items for you. These little helper classes need to be built all the time for sorted lists and other such uses. However, it is amazingly easy to get something out of alignment. So for argument sake lets stick with something simple: "Compare two strings as being equal, allowing nulls to be used such that 2 nulls return true."

I always love a good laugh and this one is great. The developers and testers at Google have put up a great "How to Write 3v1L, Untestable Code" article with tongue in cheek and enough sarcasm to really tickle your thought processes. In reality is a list of things not to do as a developer. I love the reverse style delivery. You can find the complete post here: Google Testing Blog (http://googletesting.blogspot.com/2008/07/how-to-write-3v1l-untestable-c...).

Well in a moment of testing need I decided to determine if the backups where working. So I took a backup of the database and restored it to an entirely different database service. I altered the database handler to point at the new database service and kicked the web services.

What a surprise it actually all came back up just like it is supposed to.

I am in shock. Not only are all the forums back in place, the posts are there, the blogs are there and all the test user data is there too.

== ShUnit ==

:Target: All POSIX (Linux/BSD/UNIX-like OSes)
:URL: http://shunit.sourceforge.net/
:Latest Version: 1.3 (15 Jan 2005)

:A unit testing framework for the Bourne shell family of shells modeled after JUnit. This has not been updated since 2005 and I think the project is defunct.

== shUnit2 ==

:Target: All POSIX (Linux/BSD/UNIX-like OSes)
:Latest Version: 2.1.1 (13 Jul 2007)
:URL: http://shunit2.sourceforge.net/
:Documentation: http://shunit2.svn.sourceforge.net/svnroot/shunit2/trunk/source/2.1/doc/...

== Overview Database Schema Version Control ==

It seems that version control for database schema changes has traditionally received little developer attention. Almost everyone just goes ahead and changes database schema, trying to keep it backwards-compatible.

That’s possible if the change is small or non-intrusive (as it is in most cases). For more complex changes you could create ad-hoc script which makes necessary alterations and data conversion.