>Here's my understanding as of now.
>
>If I were writing a function
>
>bool IsValidContact(Offerer objOfferer, Accepter objAccepter,
>TermsAndConditions objTermsAndConditions);
>
>
>Before writing the function, I'd enlist all the conditions that must be
>met for a contract to be valid. Something along the lines of:
>
>1. There must be a valid offer made by an offerer;
>2. There must be an unconditional, voluntary acceptance of the offer;
>3. The offerer and accepter must be above the age of minority;
>4. There must be a valid consideration (quid pro quo).
>
>Though there are many more conditions, for the sake of simplicity, let
>us stick to only the above four conditions.
>
>Going from the above four, I'd translate them into code precondition
>checks as follows:
>
>
>1. Assert (objOfferer != null)
>2. Assert (objAccepter.Acceptance.IsVoluntary() &&
>objAccepter.Acceptance.IsUnconditional())
>3. Assert ((objOfferer.Age >= ObjLawOfMinority.MinimumAge) &&
>((objAccepter.Age >= ObjLawOfMinority.MinimumAge))
>4. Assert (objTermsAndConditions.Consideration.Value > 0)
>
>
>These four would be the basis of unit tests after writing code.
>
>In the implementation, I'd use Design By Contract (DBC) style
>assertion:
>
>if (objOfferer == null)
>    return false;
>
>if (SomeOtherCondition Not Met)
>    return false;
>
>
>
>Or I might use the straight-forward-one-return-path style design like,
>
>
>if (objOfferer)
>    if (SomeOtherCondition Met)
>        return true;
>
>
>
>After writing the implementation of the above function, I'd write unit
>test scripts to test each of the above conditions. These would be
>seperate functions that would call the function IsValidContract with
>invalid and valid values against each of the above four conditions we
>outlined.
>
>Now, let me in on some terminology. Which of the above are test cases
>and what is the unit tests here?
>
> 
>

> None of these are tests at all, they are merely good validation of
> parameters in the code.  Testing means beating up the application with
> valid and nonsense data input to verify the application is doing what it
> is supposed to be doing.  Typically, a unit test is performed by the
> programmer, because he can step through the code while executing and
> tracking values through the functions, and to verify he hasn't broken
> anything else that was already working.  Test cases are typically
> performed by QA, or at least someone other than the programmer, ideally
> with a written test plan and expected results.
>
> Tom
>
>
> Water Cooler v2 wrote:
>
>> Here's my understanding as of now.
>>
>> If I were writing a function
>>
>> bool IsValidContact(Offerer objOfferer, Accepter objAccepter,
>> TermsAndConditions objTermsAndConditions);
>>
>>
>> Before writing the function, I'd enlist all the conditions that must be
>> met for a contract to be valid. Something along the lines of:
>>
>> 1. There must be a valid offer made by an offerer;
>> 2. There must be an unconditional, voluntary acceptance of the offer;
>> 3. The offerer and accepter must be above the age of minority;
>> 4. There must be a valid consideration (quid pro quo).
>>
>> Though there are many more conditions, for the sake of simplicity, let
>> us stick to only the above four conditions.
>>
>> Going from the above four, I'd translate them into code precondition
>> checks as follows:
>>
>>
>> 1. Assert (objOfferer != null)
>> 2. Assert (objAccepter.Acceptance.IsVoluntary() &&
>> objAccepter.Acceptance.IsUnconditional())
>> 3. Assert ((objOfferer.Age >= ObjLawOfMinority.MinimumAge) &&
>> ((objAccepter.Age >= ObjLawOfMinority.MinimumAge))
>> 4. Assert (objTermsAndConditions.Consideration.Value > 0)
>>
>>
>> These four would be the basis of unit tests after writing code.
>>
>> In the implementation, I'd use Design By Contract (DBC) style
>> assertion:
>>
>> if (objOfferer == null)
>>    return false;
>>
>> if (SomeOtherCondition Not Met)
>>    return false;
>>
>>
>>
>> Or I might use the straight-forward-one-return-path style design like,
>>
>>
>> if (objOfferer)
>>    if (SomeOtherCondition Met)
>>        return true;
>>
>>
>>
>> After writing the implementation of the above function, I'd write unit
>> test scripts to test each of the above conditions. These would be
>> seperate functions that would call the function IsValidContract with
>> invalid and valid values against each of the above four conditions we
>> outlined.
>>
>> Now, let me in on some terminology. Which of the above are test cases
>> and what is the unit tests here?
>>
>> 
>>