Skip to content

Commit

Permalink
still being lazy with contract for check
Browse files Browse the repository at this point in the history
  • Loading branch information
magwas committed Feb 26, 2023
1 parent af0540c commit 2f364ba
Show file tree
Hide file tree
Showing 6 changed files with 62 additions and 12 deletions.
31 changes: 31 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
# Test-time Contract Driven Development framework

In formal verification of algorithm we state relationships about and between its inputs, outputs, internal and external states.
The set of those relationships are called contracts.

In TDD, we actually define those contracts with test cases.
Test cases can be thought as the code verifying the contract of a service, by testing it with a representative parameter for all cases of the logic of the service.

To conduct those tests, we need stubs for underlying services; services used by the service under test.
The stubs are also providing information using the representative parameter sets.
Those stubs are code providing the needed information about the contract of the underlying service.

That means that the contract of most of those services are coded more times: once as test cases verifying the service, and one or more times as stubs providing information about the service as an underlying one.

Coding the whole information once have the following advantages:
* less coding effort: the information is coded only once, instead of two or more times
* more structural approach: while there are approaches to make sure that test coverage is adequate, stubs are written in a more or less ad-hoc manner.
Using the contract for both goals means that the process can use the structured approach of testing.
* integration assurance: as the same code is used for stubs and tests, we know that the information used about an underlying service is actually tested, so the service actually works as the stubs say it should work.

It can be argued that this approach is not actually contract-driven: we are not coding the contract with the mathematical precision needed in algorithm verification, we are still relying on test cases.
In other words we are not defining the contract formally and fully, just pinning it along representative data points.
So maybe the name is not correct. If you have a better name, just tell us.

Existing tools for contract driven development do not concentrate on testing; they either concentrate on
* formal verification; this makes testing unnecessary, but needs very involved work
* run-time verification; as a way to augment formal verification with a less resource-intensive way for less critical parts of the software, and protect the critical parts against forbidden inputs.

This library is a work in progress. For an example of how a contract looks like see the test directory


6 changes: 1 addition & 5 deletions src/shall/ThenReturn.py
Original file line number Diff line number Diff line change
@@ -1,10 +1,6 @@
from typing import TypeVar, ParamSpec, Self

from shall.ShallEntity import ShallEntity

P = ParamSpec("P")
R = TypeVar("R")

from shall.ShallEntity import ShallEntity, P, R

class ThenReturn(ShallEntity[P, R]):
def thenReturn(self, returnValue: R) -> Self:
Expand Down
22 changes: 22 additions & 0 deletions test/CheckContract.py
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
from unittest.mock import Mock
from Shall import Shall
from shall.Check import Check
from shall.ShallConstructor import ShallConstructor

def callable(a:int)-> str:
return str(a)

class CheckContract:
selfMock= Mock()
selfMock.callable = callable
selfMock.parameters = ((2,),{})
selfMock.returnValue = "2"
selfMock.explanation = "explanation"
selfMock.returnConstraints = list()
selfMock.sideEffectCheckers = list()

rules = [(
Shall("checks the contract", Check[[int],str].check)
.ifCalledWith(selfMock)
.thenReturn(None)
)]
4 changes: 0 additions & 4 deletions test/IfCalledWithContract.py
Original file line number Diff line number Diff line change
Expand Up @@ -4,12 +4,8 @@
from shall.IfCalledWith import IfCalledWith
from shall.ShallEntity import ShallEntity, P, R


def checker(returnValue:Any, self:ShallEntity[P,R], otherparam: int, foo: str) -> bool:
print("---")
print(self.parameters)
expected = ((1,), {'foo': 'bar'})
print(expected)
return self.parameters == expected

class IfCalledWithContract:
Expand Down
6 changes: 3 additions & 3 deletions test/ThenreturnContract.py
Original file line number Diff line number Diff line change
Expand Up @@ -7,8 +7,8 @@
class ThenreturnContract:
mockSelf:ThenReturn[[int],str] = Mock()
rules = [(
Shall("Registers the return value", ThenReturn[[int],str].thenReturn)
.ifCalledWith(mockSelf,"42")
Shall("Registers the return value", ThenReturn[[int],str].thenReturn) #type:ignore
.ifCalledWith(mockSelf,"42") #type: ignore
.thenReturn(mockSelf)
.suchThat("the return value is registered", lambda returnValue, self, givenValue: self.returnValue == givenValue)
.suchThat("the return value is registered", lambda returnValue, self, givenValue: self.returnValue == givenValue) #type:ignore
)]
5 changes: 5 additions & 0 deletions test/testcontract.py
Original file line number Diff line number Diff line change
@@ -1,5 +1,6 @@
import sys
from unittest import TestCase
from CheckContract import CheckContract

from ExampleContract import ExampleContract
from ThenreturnContract import ThenreturnContract
Expand Down Expand Up @@ -39,3 +40,7 @@ def test_suchthat(self) -> None:
def test_thenreturn(self) -> None:
for rule in ThenreturnContract.rules:
rule.check()

def test_check(self) -> None:
for rule in CheckContract.rules:
rule.check()

0 comments on commit 2f364ba

Please sign in to comment.