I'm quite interested in the concept of software components and how those ideas can be applied to Java code. Thoughts or ideas I have on this subject get dropped here for the benefit of humanity and my own hubris.
Except where otherwise noted, all original content is licensed under a
Creative Commons License.
See details.
What a heavy title, eh? Actually, I was stewing over component interfaces. These interfaces are the contracts between components and specify the functional results of operations and whatnot.
But in order for a component to be trusted and relied upon, the contract has to go a bit further. I mean, if a new version of a component took twice as long to complete, then the contract is pretty much broken. But how can you accurately specify execution speed of a component?
So here is my idea … what if the component's unit testing measures the time and resources required and compares those against previous test runs. This way, you may not be able to guarantee that it performs in x seconds, but you can state that at least changes made to the system didn't adversely affect the speed of the component.
Most places have separate build and test systems, and if those systems are used exclusively for that purpose, then a test should run pretty much the same from run to run. Granted, there is going to have to be some leeway, but perhaps if you had a graph of all the previous runs …
This way, a new version of a component will be able to demonstrate new requirements that are based on a customer's previous experience with the current version.
My idea should be used for more than just components, but any unit testing should have this feature. Perhaps some of the larger test harness already do?
© 2003-2005, Howard Abrams • Except where otherwise noted, all original content is licensed under a Creative Commons License (see details).
|
|
|
|
|
|