Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Drivers & Stubs - confused!

Status
Not open for further replies.

GoldenHaddock

Technical User
Mar 10, 2005
23
GB
Hi there!

I'm new to all this stuff and I am doing some past questions from old tests that i have found to get up to speed with the whole thing.

there is a question regarding ships and the distances between them...i presume its just made up and isnt real

the function is:

function Ship_saftey () is
begin
read wind;
if (wind < 8)
safedist = 100;
else
safedist = 150;
endif

Pretty straight forward.

The questions asks for a driver to be written for this and im not too sure! The answer isnt given.... any pointers would be good, thanks :)

Also, does a stub simply return dummy data to test a module?
 
A driver could also be called a unit test. It's just some code to call this method with different values to see if it behaves correctly. Ideally, you write the test before the method.

BTW, "Saftey" isn't spelled correctly.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first
 
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


 
Actually, I see mock objects as being the driven part of the testing regimen, rather than the drivee.

If I have to make a call to some external system which isn't ready (still under development), or which doesn't do very well when called in a testing environment (costs money to call, or something), then you want to replace it with a mock object for your testing. It's a gray box that replicates the external interfaces of the real thing.

But when you've got some code that you've written that needs to be tested, you want to call it with some sample data to make sure it performs like you want -- sending reasonable values, unreasonable values, and some corner cases. What this code is called varies -- I've seen it called a driver (which I don't personally like, as it gets confused with device-drivers), exercise code, or lately, unit test. I like unit test code. ;-)

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top