Aspect-Oriented Test Development
Posted on April 20, 2006
I am vaguely familiar with the state of testing inside virtual machines such as JVM or .net, I also don’t know enough about aspects, but I think I understand the idea and intended application. Anyway I was reading the book about software testing, and I got an idea on how this two technology can be used together. Here is an abstract:
An aspect can be injected? in application context to test paths that are difficult to test due to same kind of exceptional condition – low memory, disk full, connection lost, driver not loaded, etc. An aspect can monitor the interaction between application and its virtual machine. It can log :-7 each method/system call and simulate a failure of any call at will. In this way a disk can be “made full”, network connection can “become disconnected”, data transmission can “be garbled” and a host of other problem simulated.
(Inspired by “A practitioner’s guide to software test design / Lee Copeland”)
I’m not sure if such system already exist. It would be an interesting project to try to implement such a system.
Filed Under Uncategorized | 5 Comments
Leave a Comment
If you would like to make a comment, please fill out the form below.
Hmmm that’s actually a really great idea that I hadn’t seen about aspects. I’m not sure how this could be implemented but it’s definitely worth looking into.
I find its already implement in every program that has exception handlers.. Meaning:
if( disk_full )
diskBool = true;
…
if( diskBool )
Free_up_Space_and_Restart
————————
Now: Lets say you want to simulate a full disk? Well, just go and in your Init() set diskBool = true;!
————-
am i missing somehting?
“if( (disk_full = write(fd, data)) == true) {} else {}” is a C++ example, I am talking about Java and .Net(thought there are almost no differences I would like to narrow problem statement in VM boundaries).
Take for example this code:
urlStr = “http://xeo.com:90/register.jsp?name=joe”;
try {
URL url = new URL(urlStr);
InputStream is = url.openStream();
is.close();
} catch (MalformedURLException e) {
// Print out the exception that occurred
System.out.println(“Invalid URL “+urlStr+”: “+e.getMessage());
} catch (IOException e) {
// Print out the exception that occurred
System.out.println(“Unable to execute “+urlStr+”: “+e.getMessage());
}
Some methods may have a lot of fine-grainted exeptions, and an application should probably handle some of them in one way and another in different way. But the condition that trigger thouse exceptions sometime very difficult to simulate.
Suppose you have a multithreaded network miltiplexer, how would you simulate a network failure in the middle of the transaction in order to test the error handling routines? Unplug the cable? With the aspects you can trigger thouse exeption at runtime of a regular unmodified application.
By intercepting an application syscall, we can test application code _without changing the source code_. Who knows what kind of nondeperministic deamons we will summon by changing code ;-)
aaah
allright i get it!
Grrr, somebody thought about it already (not the same but very close):
Robustness testing of Java server applications
Fu, C.; Milanova, A.; Ryder, B.G.; Wonnacott, D.G.;
Software Engineering, IEEE Transactions on
Volume 31, Issue 4, April 2005 Page(s):292 – 311
This paper presents a new compile-time analysis that enables a testing methodology for white-box coverage testing of error recovery code (i.e., exception handlers) of server applications written in Java, using compiler-directed fault injection. The analysis allows compiler-generated instrumentation to guide the fault injection and to record the recovery code exercised. (An injected fault is experienced as a Java exception.) The analysis 1) identifies the exception-flow “def-uses” to be tested in this manner, 2) determines the kind of fault to be requested at a program point, and 3) finds appropriate locations for code instrumentation. The analysis incorporates refinements that establish sufficient context sensitivity to ensure relatively precise def-use links and to eliminate some spurious def-uses due to demonstrably infeasible control flow. A runtime test harness calculates test coverage of these links using an exception def-catch metric. Experiments with the methodology demonstrate the utility of the increased precision in obtaining good test coverage on a set of moderately sized server benchmarks.
http://ieeexplore.ieee.org/search/wrapper.jsp?arnumber=1435351