Unit Testing and Test Cases

[Water Cooler v2]

Here's my understanding as of now.

If I were writing a function

bool IsValidContact( Offerer objOfferer, Accepter objAccepter,
TermsAndConditi ons objTermsAndCond itions);
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.Ac ceptance.IsVolu ntary() &&
objAccepter.Acc eptance.IsUncon ditional())
3. Assert ((objOfferer.Ag e >= ObjLawOfMinorit y.MinimumAge) &&
((objAccepter.A ge >= ObjLawOfMinorit y.MinimumAge))
4. Assert (objTermsAndCon ditions.Conside ration.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 (SomeOtherCondi tion Not Met)
return false;

Or I might use the straight-forward-one-return-path style design like,
if (objOfferer)
if (SomeOtherCondi tion 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?

[tomb]

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,
TermsAndCondit ions objTermsAndCond itions);
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.Ac ceptance.IsVolu ntary() &&
objAccepter.Ac ceptance.IsUnco nditional())
3. Assert ((objOfferer.Ag e >= ObjLawOfMinorit y.MinimumAge) &&
((objAccepter. Age >= ObjLawOfMinorit y.MinimumAge))
4. Assert (objTermsAndCon ditions.Conside ration.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 (SomeOtherCondi tion Not Met)
return false;

Or I might use the straight-forward-one-return-path style design like,
if (objOfferer)
if (SomeOtherCondi tion 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?

[MFB]

He means unit testing with something like NUnit.

tomb wrote:

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,
TermsAndConditi ons objTermsAndCond itions);
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.Ac ceptance.IsVolu ntary() &&
objAccepter.Acc eptance.IsUncon ditional())
3. Assert ((objOfferer.Ag e >= ObjLawOfMinorit y.MinimumAge) &&
((objAccepter.A ge >= ObjLawOfMinorit y.MinimumAge))
4. Assert (objTermsAndCon ditions.Conside ration.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 (SomeOtherCondi tion Not Met)
return false;

Or I might use the straight-forward-one-return-path style design like,
if (objOfferer)
if (SomeOtherCondi tion 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?

[Homer J Simpson]

"Water Cooler v2" <wt*****@yahoo. com> wrote in message
news:11******** **************@ p10g2000cwp.goo glegroups.com.. .

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).

What happens if the offer is zero? Negative? Extremely large? What if the
ages are null? Zero? >100? What if the consideration is unstated? Has no
intrinsic value you can detect?