Dec
21
Written by:
QCTO Blog
Monday, December 21, 2009
Sometimes you need to reference the value of an IN argument (an input, in Code Tester terminology) in your outcome. For example, under certain circumstances, the string returned by your function should be the same as the input value. Or perhaps the out value should be some part of the input value.
You could hard-code the same value you supplied in the Input Grid, but then if you change the input value, you have to change the outcome value as well. That's not a great solution.
Code Tester instead gives you two different ways to reference the input value indirectly:
- Functions in the qu_result_xp package that accept the name of the argument and returns it value
- Reference the name of the variable that Code Tester will declare and then assign the IN value to it before the program is run.
Let's take a look at both these techniques for a very simple example. Suppose I want to test this function:
FUNCTION first_three (string_in IN VARCHAR2) RETURN VARCHAR2
IS
BEGIN
RETURN SUBSTR (string_in, 1, 3);
END;
I start up Test Builder and create a new test case. I enter "abcdefg" in the input grid for string. I will also open up the Properties Window for that input.
I see this:
Notice the variable name "i_STRING_IN." That is the name of the variable that will be used to store the input value and pass it to first_three. You can change this to anything you like, but the default is usually fine.
OK, now let's shift focus to the Outcome side of the test case. The function is supposed to return a string that is just a portion of the input value (first three characters). I could therefore create an outcome like this:
But this only proves that the correct value is returned for this one string ("abcdefg"). And, as noted above, if I ever want to change the input value, I must change the outcome value as well.
Instead of hard-coding the return value, I can open the Properties Window for the outcome's expected result:
and then in the "Expression of Query" field I can enter either of the following:
SUBSTR (i_String_in, 1, 3)
or
SUBSTR (qu_result_xp.argval_varchar2 ('STRING_IN'), 1, 3)
The first approach simply relies on the name of the input variable remaining "i_string_in." The second approach relies on the underlying API in the qu_result_xp package to look up the value of the IN argument with the specified name.
More generally, the API approach can be described as: when you want to get the value of an IN argument for a test case, you will call a program of this form:
qu_result_xp.argval_ < datatype > ('< argument_name >')
All of the following are currently supported:
FUNCTION argval_varchar2 (argument_name_in IN VARCHAR2) RETURN VARCHAR2;
FUNCTION argval_clob (argument_name_in IN VARCHAR2) RETURN CLOB;
FUNCTION argval_date (argument_name_in IN VARCHAR2) RETURN DATE;
FUNCTION argval_number (argument_name_in IN VARCHAR2) RETURN NUMBER;
FUNCTION argval_boolean (argument_name_in IN VARCHAR2) RETURN BOOLEAN;
FUNCTION argval_timestamp (argument_name_in IN VARCHAR2) RETURN TIMESTAMP;
FUNCTION argval_timestamp_tz (argument_name_in IN VARCHAR2)
RETURN TIMESTAMP WITH TIME ZONE;
FUNCTION argval_timestamp_ltz (argument_name_in IN VARCHAR2)
RETURN TIMESTAMP WITH LOCAL TIME ZONE;
FUNCTION argval_interval_ds (argument_name_in IN VARCHAR2)
RETURN INTERVAL DAY TO SECOND;
When you pass the name of the argument, be sure to use a case that matches the actual argument name. In other words, unless the argument name is contained within double quotes, pass the argument name as UPPER CASE.
Another advantage of referencing the input value by name, rather than by the hard-coded value, is that you can use random values or lists of values to dynamically generate many different inputs (and therefore different test cases), all with the same/single outcome.
Consider the testing of first_three. So far I have built a single test case for a specific input value of "abcdefg". I am reassured that I get the right answer for that one value, but I'd feel lots more confident if I could "throw" lots of different strings at it and ensure that in all cases, the function returned the correct answer.
To do this, I can go back to the input for the test case and change the value from a single literal to a randomly generated list of, say, 100 strings with lengths varying from 10 to 32767:
And now every time I run my test, Code Tester will generate 100 new strings and run first_three for each. You see the partial results below:
I hope this gives you a clear understanding of how you can reference IN argument values by name, and make your test cases that much more flexible and useful.