jar@hila.hut.fi (Jari Arkko) (10/12/89)
I'm looking for information on testing object-oriented or data-driven programs. I have not been able to find any references, so if anyone out there knows papers about this area, please point me to them. Thank you in advance, Jari +----------------------------------------------------------------------------+ | | | Message overflow area | | | +----------------------------------------------------------------------------+ Jari Arkko (jar@hutcs.hut.fi) tel. +358 90 8055783 Helsinki U of Technology +----------------------------------------------------------------------------+ | | | Message overflow area | | |
eberard@ajpo.sei.cmu.edu (Edward Berard) (10/13/89)
In article <25704@santra.UUCP>, jar@hila.hut.fi (Jari Arkko) writes: > > I'm looking for information on testing object-oriented or data-driven > programs. I have not been able to find any references, so if anyone > out there knows papers about this area, please point me to them. > Before I answer your question, I want to make two statements: 1. I do not consider "data-driven" to be the same thing as "object-oriented." Objects are not data, and data are not objects. For examples of data-driven approaches see the work of J.D. Warnier, Michael Jackson (JSP), and Ken Orr among others. I will restrict my remarks to testing of object-oriented software. 2. I will assume that the reader already has a background in software testing technology. For example, I will assume that the reader has an understanding of, and knows how to apply: a. white-box testing, e.g., basis path testing b. black-box testing, e.g.: - equivalence class testing - boundary value analysis - cause-effect graphing - error guessing c. gray-box testing, e.g.: - singularities - mutation testing There are many literature references on software testing technology. I would like to avoid supplying a list of references on general testing technology ... if I can. Most of the more traditional testing techniques I have just mentioned also apply to the testing of object-oriented software. Testing of object-oriented software, however, introduces a number of interesting problems, e.g.: 1. Since objects (and classes) are often implemented as syntactically and semantically encapsulated collections of items, the usual concept of integration testing does not apply at the object and class level. For example, suppose an object (class) exports (advertises, or has in its interface) two, or more operations. Do you remove all the operations except one, test the object (class) with that one operation, then add the next operation, and repeat the process? (This does not make sense, please don't do it this way.) 2. Since objects are supposed to be black boxes, how can a tester be sure that a desired state change actually took place? For example, if I add an item to a list object, how do I know that it was actually added? If I use one, or more, operations in the interface, that implies I have some confidence in them. How did I get that confidence? If I use a debugger (double :-(), I am violating a number of testing axioms, e.g., I am not testing the software as it will actually be deployed. 3. Since object-oriented systems are naturally concurrent (at least conceptually), you have all the problems of testing concurrent software, e.g., non-determinism. For example, systematically construct a series of test cases to _adequately_ test a Playground or PetWorld application. (See the proceedings from OOPSLA '89.) There have been a number of articles written on testing of concurrent software, e.g., the work of Dr. Tai at North Carolina State University, and a recent IEEE tutorial on concurrent testing. However, most of the work which has been done in the area of testing black boxes, and testing program units larger than a subprogram has been done in the Ada arena. Look for articles on testing packages and testing private types. If I get the time, I will post some specific references at a later date. -- Ed Berard Phone: (301) 353-9652 FAX: (301) 353-9272
sakkinen@tukki.jyu.fi (Markku Sakkinen) (10/13/89)
In article <601@ajpo.sei.cmu.edu> eberard@ajpo.sei.cmu.edu (Edward Berard) writes: >In article <25704@santra.UUCP>, jar@hila.hut.fi (Jari Arkko) writes: >> >> I'm looking for information on testing object-oriented or data-driven >> programs. I have not been able to find any references, so if anyone >> out there knows papers about this area, please point me to them. >> >[...] >[a lot of useful discussion] >[...] > 3. Since object-oriented systems are naturally concurrent (at > least conceptually), you have all the problems of testing > concurrent software, e.g., non-determinism. [...] >[...] What? In my opinion, object-orientation and concurrency are totally independent features; most current OO languages are just as sequential as Pascal or Fortran. It is another thing that object-orientation is a nice basis for building good concurrent languages, too. The important thing in this context is that you need _not_ tackle the complexities of concurrency and indeterminism, which is very lucky for you. Markku Sakkinen Department of Computer Science University of Jyvaskyla (a's with umlauts) Seminaarinkatu 15 SF-40100 Jyvaskyla (umlauts again) Finland