Actually Chip, I disagree that a "driver could also be called a unit test.", Unless you can shed some light on this.
Instead, I see a Driver as playing a supplemental role to Unit Tests. It stands to reason that Drivers stand in for real objects, acting as proxies. They participate in tests, they are not tests.[?]
It's interesting that the original poster (GoldenHaddock) used the term "Driver". Nothing wrong with that but after doing some research I can confidently say that a Driver is a specialized piece of software(code,program) that knows how to handle a piece of hardware attached to a computer (Printer). It allows the OS to communicate with this Device through the Drivers simplistic interface.
I understand that GoldenHaddock is not writing any low-level drivers but I see what he's trying to do. We call these Drivers in OO "MockObjects". Mock objects simulate real objects. A test can be written against some simulated object to speed up testing, logging, etc.
I am really fascinated by the "Driver" terminology, and while some oo purist out there may just take my head off for this statement, I can honestly say that thinking of the Infastructure layer as a system of drivers may just help programmers to write more extensible and flexible code.
Their level of thinking will be realized even further when they start writing things like DAL's that communicate with an external storage medium (call it a device?). They will realize that multiple storage drivers should be written and be made swappable at will. Without this notion, a programmer may just lock himself into Oracle for example, crippling his system when the boss wants to persist data to SQLServer later on.
Ok, If you follow some kind of architecture, you might implement the 4 layer model where the very last layer is focused on technology, it deals with the harsh outside world, things like Relational Databases, FileStreams, Printers, Biometric Scanners, Integration Gateways, etc...
The layer just above the Infastructure is the Domain. The Domain might need to persist a Person object to a storage medium, so it relies on some kind of DAL Driver. The infastructure might just allow persistence to different mediums via a DbDalDriver, XmlDalDriver, FlatfileDalDriver and how about a VirtualPersistenceDriver, that stores data in memory, no real persistence in that one, so it's perfect for a quick unit test.
Dont know if this will ring a bell but it's exactly how windows work when you create Virtual Drives, or plugin a thumbdrive and it shows up as a RemovableDrive...Polymorphic behavior at play here, extremely powerful. Rob Martin calls this the Open Closed Principal.
Sorry, I will cut this short. As for GoldenHaddocks example, I don;t see much need for a Driver/Mock object of any sort unless reading Wind can come from different devices. Your function is in place already to write a quick test against it and preforms any assertions to pass it.
Now I dont know what your business rules are, but it seems like some things are missing above, like Ships? What is it calculating distance for? And Distances between 2 or more objects?
Here is some pseudo code on how it's done in C#:
[Test()]
public void TestSafteyDistance() {
Calculator aCalculator = new SafetyDistanceCalculator();
Distance aDistance = aCalculator.GetSafetyDistance(WindDevice.CurrentSpeed());
Assert.IsTrue(aDistance != Distance.Impact);
}
[Test()]
public void TestSafteyDistance() {
Calculator aCalculator = new RoverDistanceCalculator();
Distance aDistance = aCalculator.GetSafetyDistance(WindDevice.CurrentSpeed());
Assert.IsTrue(aDistance != Distance.Impact);
}
[Test()]
public void TestSafteyDistance() {
Calculator aCalculator = new FakeDistanceCalculator();
Distance aDistance = aCalculator.GetSafetyDistance(WindDevice.CurrentSpeed());
Assert.IsTrue(aDistance != Distance.Impact);
}
Don't quote me on this sample, but the purpose is to show
how tests are written against MockObjects.
Feedback is appreciated.
-Edward J. Smith
