Toad World® Forums

False Positive Outcome


#1

I have a function that returns a SYS_REFCURSOR. I set up a test case with an outcome of the following:

A. Data Changed by Program -> RETURN Clause
B. Test Type -> “Count > 0”
C. Expected Results -> (n/a)

When the function returns null, the test is successful. However, if I change the outcome to:

A. Data Changed by Program -> RETURN Clause
B. Test Type -> “Count >”
C. Expected Results -> 0

then the test case fails (correctly). The workaround is easy enough, but any idea why the first method would give a false positive?

Thanks!
Mitch


#2

Sorry, Mitch, looks to me like a bug. I will see if I can reproduce and if so, hopefully fix it for 1.8.3.

Thanks, SF


#3

Actually, Mitch, now I am trying to reproduce and I am confused.

What do you mean by “When the function returns null”?

An open CV that returns no rows?

A CV that has not been opened at all?

And you say “then the test case fails (correctly)”

What do you mean? The test showed RED because there are no rows in the CV? If so, what is the problem?

Thanks, SF


#4

Sorry for the confusion. Let’s try to clarify …

The function issues “OPEN myRefCursor FOR SELECT …”
So the problem arises when the select returns 0 rows. In that case, the Test Type of “Count > 0” evaluates to True.

WORKAROUND:
In the same test case (i.e. 0 rows), if I change the Test Type to “Count >” and set Expected Results to “0”, then the test case would fail (Red frown face) - which is correct and as I would expect.

Does that help?

(FYI, it appears to behave similarly with test cases using “Count = 0” and “Count < 0” as well)

Thanks,
Mitch


#5

Mitch, what version are you using? I have tried this on 1.8.2 and 1.8.3 and I don’t see a problem. Perhaps you could provide me with a support bundle that includes the program you are testing? There may be some other interaction going on here…

Thanks, SF


#6

OK, I’m going to call this a false alarm. I switched my outcomes back and they work fine now.

For background, you got me thinking about Test Driven Development at Collaborate 09. I actually ran into this issue when I first created test cases and there was only a stub for the function, which returned NULL. As you can imagine, I was a little concerned when my test cases SUCCEEDED with just stubs there.

I appreciate the feedback, and sorry for cycling you on this.

Take care,
Mitch


#7

Ah, yes, false positives are very disturbing…for this reason, I have moved from using

RETURN NULL;

to something like this:

RETURN ‘this value should never be returned’;

:slight_smile:

SF


#8

Hey, that’s not a bad idea. Thanks for the suggestion!

-Mitch