Difference between revisions of "Assertion Settings"
m (→Introduction) |
m (→Critics) |
||
| Line 21: | Line 21: | ||
==Critics== | ==Critics== | ||
| − | When the user specifies the assertions for a class he expresses a certain level of trust or mistrust towards it. When he enables invariant checking for a class he is not shure wether the specified invariants really hold, so they need to be checked. The same thing is true for loop variants, postconditions and checks. | + | When the user specifies the assertions for a class he expresses a certain level of trust or mistrust towards it. When he enables invariant checking for a class he is not shure wether the specified invariants really hold, so they need to be checked. The same thing is true for loop variants, postconditions and checks. Whereas for preconditions there is an ambiguity: |
#He might say, that he doesn't trust the callers of the class, so the preconditions of this class need to be checked. | #He might say, that he doesn't trust the callers of the class, so the preconditions of this class need to be checked. | ||
#Or he might not trust the class to hold the preconditions required by features it calls, so all the preconditions of the features called by this class need to be checked. | #Or he might not trust the class to hold the preconditions required by features it calls, so all the preconditions of the features called by this class need to be checked. | ||
| − | The current version of EiffelStudio uses the first approach. | + | The current version of EiffelStudio uses the first approach. When the user indeed mistrusts that the class holds the preconditions of the feature it calls, he needs to enable precondition checking for all the called classes. This will result in a big slow down of the system. |
| + | |||
| + | |||
| + | |||
| + | ====A common pattern for assertions=== | ||
| + | In most situations | ||
| + | |||
| + | One would typically completely trust a class from a library provided by a third party and dissable all kinds of assertion checks on the whole library. On the other side | ||
Revision as of 15:14, 16 October 2006
Author: Matthias Konrad
Introduction
The Eiffel Language specifies several assertion types:
- Preconditions
- Postconditions
- Invariants
- Loop variants
- Checks
In theory these assertions should be checked all the time. In practice, especially when working with huge systems, this is not possible. (Quite often it is not even possible during the testing phase of the system.) It is thus nessecary to decide which assertions should be tested.
It is not sufficient to just enable or disable a certain assertion kind for the whole system. Large systems are composed of smaller parts and reused components (like the base library). These are typically tested independently (unit level testing). It should thus be possible to disable assertion testing on the tested part and enable it on the other parts.
In EiffelStudio the user has to decide which assertions need to be checked. He can do this on various levels (for each assertion kind):
- Class
- Cluster
- Library
- System
Critics
When the user specifies the assertions for a class he expresses a certain level of trust or mistrust towards it. When he enables invariant checking for a class he is not shure wether the specified invariants really hold, so they need to be checked. The same thing is true for loop variants, postconditions and checks. Whereas for preconditions there is an ambiguity:
- He might say, that he doesn't trust the callers of the class, so the preconditions of this class need to be checked.
- Or he might not trust the class to hold the preconditions required by features it calls, so all the preconditions of the features called by this class need to be checked.
The current version of EiffelStudio uses the first approach. When the user indeed mistrusts that the class holds the preconditions of the feature it calls, he needs to enable precondition checking for all the called classes. This will result in a big slow down of the system.
=A common pattern for assertions
In most situations
One would typically completely trust a class from a library provided by a third party and dissable all kinds of assertion checks on the whole library. On the other side
