I am interested in the area of program complexity. Program complexity is concerned with what makes a program or other software product difficult to work with. Of course, what makes a program difficult depends in part on the task being performed and on the individual doing the task. I concentrate, however, on that aspect of software complexity that comes from the program itself.
The particular task I have been examining for the last three years is the unit testing of single modules. I believe the interactions among different parts of the module are responsible for much of the complexity. Those interactions fall into several categories including: (1) this unit must be executed before that unit since the first unit provides a value for the second unit or consumes values ( in a file or data structure) that make other values available to the second unit; (2) while this unit does not need to be executed before that unit, the order in which they are executed will affect the meaning of the second unit ( perhaps both) since they share a value-holder. Since dependencies seem to depend on data, both the actual values and its structure, I developed a new method of unit testing called "data structure testing". This method looks at the patterns of data structure growth, usage, and shrinkage that can occur during execution. Test cases are developed for each possible pattern using a grammatical approach.
Much of my interest in unit testing derives from the relatively new structures that now are used in many programs. These structures include the use of abstract data types, patterns, and generics. I think it very possible that these structures make possible or desirable new testing paradigms.