• No results found

Testing object Interactions Grüner, A.

N/A
N/A
Protected

Academic year: 2021

Share "Testing object Interactions Grüner, A."

Copied!
2
0
0

Bezig met laden.... (Bekijk nu de volledige tekst)

Hele tekst

(1)

Testing object Interactions

Grüner, A.

Citation

Grüner, A. (2010, December 15). Testing object Interactions. Retrieved from https://hdl.handle.net/1887/16243

Version: Corrected Publisher’s Version

License: Licence agreement concerning inclusion of doctoral thesis in the Institutional Repository of the University of Leiden

Downloaded from: https://hdl.handle.net/1887/16243

Note: To cite this publication please use the final published version (if applicable).

(2)

Stellingen

behorende bij het proefschrift

Testing Object Interactions

door Andreas Gr¨uner

1. Adding re-entrant monitors to a concurrent component-based pro- gramming language increases the uncertainty regarding the observable behavior at the component’s interface.

2. Although mock object testing rather has a focus for practical appli- cations it is possible and useful to give this testing approach a formal basis.

3. If unit tests are to be conducted by software developers then the test specification language should consist of the target programming lan- guage extended by additional specification statements.

4. It is arguable whether software developers should write their own unit tests.

5. In an object-oriented setting it does not make sense to distinguish unit and integration testing.

6. For testing object-oriented units one should prefer an interaction-based to a state-based testing approach.

7. A lot of unit tests seem to be practically of no use but are written only to fulfill unit testing guidelines or coding rules.

8. If all software products had to be formally verified then probably the most complex application available would be a text-oriented calculator.

9. Randomness is just an illusion caused by our limited perception.

Referenties

GERELATEERDE DOCUMENTEN

The characterization will help us to find an appropriate design of the specifi- cation language, which will be a careful balance between two goals: we will use programming constructs

A program consists of a list of global variables, a set of classes, and a main program (or main body). Note, that due to simplicity, our language slightly differs from Java already

Thus, the original statement of an (outgoing) method call, x = e.m(e), is now split into the actual outgoing call and its corresponding incoming return such that the new

Thus, if no matching incoming call expectation can be found, then, before we consider the constructor call to be unexpected, we additional check if an internal object creation

As for the remaining inherited typing rules regarding statements, they are again extended by the new name context. Some of them are also adapted regard- ing the control context. A

Finally, we sketch how the code generation algorithm of the single-threaded setting can be modified in order to generate test programs also for

Consequently, the thread configuration mapping is extended by the new thread n, where n is mapped to its thread class and a new call stack consisting of the method or, respectively,

Note, furthermore, that we need not to provide a specification statement for the expectation of incoming spawns. To understand the reason, consider the case that we do provide such