As a proponent of modern software development practices, I have a soft spot for unit testing. It also helps that I spend most of my after work coding time in Ruby, whose community has unit testing in its DNA. If you're not familiar with the practice, unit testing involves writing scenarios in code that prove a given object or method you have created behaves correctly.
My personal favorite unit testing framework is called rspec. Here's a quick example of rspec:
it "should score 0 for gutter game" do 20.times { @bowling.hit(0) } @bowling.score.should == 0end
As you can see, this block of code decribes a test proving that a gutter game works correctly. It bowls no pins 20 time and then tests the assertion that the game's score is also zero. The syntax is quite simple, clean and easy to read. And once this test is written, it's an asset that becomes more valuable as the project becomes more complex. It's an investment.
Unit testing allows you to trust code you aren't currently working on. How do you know the new code doesn't break the old code? How do you know there aren't side-effects to your changes? Run your unit tests and see if they pass. Unit tests allow you to assert that your application is still correct, over time and whenever you need, for a one-time cost. They also provide a kind of technical documentation for your code by showing it in action and describing scenarios that should work and scenarios that are supposed to fail.
I wonder if there's not an application for unit testing in trading partner communities. Your supply chain is really just a big Service Oriented Architecture, right? Loosely coupled systems (you and your partners) exchange objects and methods (transactions). Compliance rules and tools like our Order Lifecycle Visiblity are employed to validate across documents or enforce business rules on a per-transaction basis. I wonder if we couldn't use those rules as a test suite that could be run arbitrarily? You could determine, for example, whether a change in your policy would break by making a change to your test cases and running the tests against a set of X recent transactions per partner to look for any that fall out. You would then know who is likely to already be in compliance with the new policy before even putting it in place.
This idea of thinking of the supply chain as a multi-company SOA might open up some new ideas for improving quality and consistency. I think there's some best practices we can borrow from recent advances in the development world and apply them to the supply chain.
