From a13f6f110885d697a28d03bf0b3db221c68401d5 Mon Sep 17 00:00:00 2001 From: eiffel-org Date: Tue, 5 May 2026 15:24:25 +0000 Subject: [PATCH] Updated wikipage Design by Contract and Assertions. (Signed-off-by:roc_admin). git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@2511 abb3cda0-5349-4a8f-a601-0c33ac3a8c38 --- .../eiffel-net/design-contract-and-assertions.wiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/documentation/25.12/solutions/dotnet/eiffel-net-language/eiffel-net/design-contract-and-assertions.wiki b/documentation/25.12/solutions/dotnet/eiffel-net-language/eiffel-net/design-contract-and-assertions.wiki index 5e558fb3..72d0fa4b 100644 --- a/documentation/25.12/solutions/dotnet/eiffel-net-language/eiffel-net/design-contract-and-assertions.wiki +++ b/documentation/25.12/solutions/dotnet/eiffel-net-language/eiffel-net/design-contract-and-assertions.wiki @@ -1,4 +1,4 @@ -[[Property:modification_date|Tue, 05 May 2026 15:23:25 GMT]] +[[Property:modification_date|Tue, 05 May 2026 15:24:25 GMT]] [[Property:publication_date|Tue, 05 May 2026 15:23:25 GMT]] [[Property:title|Design by Contract and Assertions]] [[Property:weight|5]] @@ -27,7 +27,7 @@ Design by Contract is built around a model for software correctness that is real Suppose there is software routine called s. If we were going to test s, we would probably devise some test inputs or test values to be in place when s starts and then observe what things look like after s completes. If they look the way we think they should then that leads us to believe that S is working correctly for those test inputs. -We can generalize and formalize that process a bit, taking it back from testing an into design. If indeed we know what it means for s to be correct, then we should be able to make a statement of any conditions that must be true prior to executing s. That is, we will state the conditions required for it to be possible for s to run correctly. We call this statement of preconditions for success s's precondition. +We can generalize and formalize that process a bit, taking it back from testing and into design. If indeed we know what it means for s to be correct, then we should be able to make a statement of any conditions that must be true prior to executing s. That is, we will state the conditions required for it to be possible for s to run correctly. We call this statement of preconditions for success s's precondition. Likewise we should be able to make a statement of the conditions that will be true always if s works correctly. This we call s's postcondition.