[Setools] What we have yet

[Klaus D. Witzel]

Hi Alex,

on Mon, 26 Jun 2006 11:15:41 +0200, you wrote:

>> Sure, agreed. But let me give an example problem area which cannot be  
>> addressed by extending OB. Let's say we have to deveop three methods,  
>> isUnaryToken, isBinaryToken and isKeywordToken. The tests for them must  
>> satisfy
>>  isUnaryToken not or: isBinaryToken not.
>>  isUnaryToken not or: isKeywordToken not.
>>  isBinaryToken not or: isKeywordToken not.
>> (note that there is not need for []'s in test clauses).
>>
>> How shall the problems arising from symmetry and neverending recursion  
>> in these three simple example statements be addressed?
>
> Why this "symmetry" has to be explicit ?

Stupid me, the test statements can be duplicated. Recall that the issue at  
hand is, when method a1 is tested, it "leaves" a scenario in which method  
b2 is then tested (same as reading / executing code from left to right,  
"transitive" tests, sharing a particular context). So in test of  
isUnaryToken we have
	isUnaryToken not or: isBinaryToken not.
	isUnaryToken not or: isKeywordToken not.
In test of isBinaryToken we have
	isBinaryToken not or: isUnaryToken not.
	isBinaryToken not or: isKeywordToken not.
And similiar for the third. Let me add that, these test statements must be  
driven by test data for testing success and failure.

Any idea for tool support in this area (other than OB for handcoding)?

/Klaus

P.S. sorry List for being verbose with these trivial looking examples.