utPLSQL/documentation/src/samepack.html at master · pascal8/utPLSQL · GitHub

History

203 lines (175 loc) · 6.04 KB

Raw

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

193

194

195

196

197

198

199

200

201

202

203

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<head>

</head>

<body>

<h1>Put Test Code in Same Package</h1>

<p>

In some cases (usually when your packages are small and the code you

need to write to construct your tests is also constrained), you will not

want to bother with creating a separate package to test your code. To do

this, you will put the setup, teardown and unit test procedures inside

the package specification and body. We look at two examples:

</p>

<ul>

<li><a href="#str">Testing a simple string function</a></li>

<li><a href="#coll">Testing the population of a collection</a></li>

</ul>

<h3><a name="str">Testing a simple string function</a></h3>

<p>

Suppose I have my basic sting package, containing (for now at least) just

a single function:

</p>

<pre>

/*file str.pks */

CREATE OR REPLACE PACKAGE str

FUNCTION betwn (

string_in IN VARCHAR2,

start_in IN PLS_INTEGER,

end_in IN PLS_INTEGER

)

RETURN VARCHAR2;

END str;

</pre>

<p>

Now it is time to test the function. I really don't want to bother with

a separate package; let's keep it together. To do this, I change the specification

to:

</p>

<pre>

CREATE OR REPLACE PACKAGE str

FUNCTION betwn (

string_in IN VARCHAR2,

start_in IN PLS_INTEGER,

end_in IN PLS_INTEGER

)

RETURN VARCHAR2;

PROCEDURE ut_setup;

PROCEDURE ut_teardown;

-- For each program to test...

PROCEDURE ut_betwn;

END str;

</pre>

<p>

The package body contains nothing unusual; it is the same test for str.betwn

that you can find in the <a href="testfunc.html#ScalarFunction">Testing

a Scalar Function</a> example. But when I execute my test, I need to tell

utPLSQL that my test code is located in the same package:

</p>

<pre>

SQL> exec utconfig.showconfig

=============================================================

utPLSQL Configuration for SCOTT

Directory: e:\openoracle\utplsql\utinstall\examples

Autcompile? Y

Manual test registration? N

Prefix = ut_

=============================================================

PL/SQL procedure successfully completed.

SQL> exec utPLSQL.test ('str', samepackage_in => TRUE)

> SSSS U U CCC CCC EEEEEEE SSSS SSSS

> S S U U C C C C E S S S S

> S U U C C C C E S S

> S U U C C E S S

> SSSS U U C C EEEE SSSS SSSS

> S U U C C E S S

> S U U C C C C E S S

> S S U U C C C C E S S S S

> SSSS UUU CCC CCC EEEEEEE SSSS SSSS

SUCCESS: "str"

</pre>

<h3><a name="coll">Testing the population of a collection</a></h3>

<p>

Collections are very useful structures, but they can be difficult to analyze

and compare. utPLSQL provides the utAssert.eqColl and utAssert.eqCollAPI

programs to help you do this.

</p>

<p>

For this example, consider the fileIO package: it implements a path

feature for the UTL_FILE package. In other words, you request to open a

file and your file-opening program will search through each of the directories

in the path in sequence until it finds the file or exhausts the list. Here

is the specification of this package:

</p>

<pre>

/*file filepath1.pkg */

CREATE OR REPLACE PACKAGE fileIO

c_delim CHAR(1) := ';';

dirs dirs_tabtype := dirs_tabtype ();

-- Unit test list

ut_dirs dirs_tabtype := dirs_tabtype ();

PROCEDURE setpath (str IN VARCHAR2, delim IN VARCHAR2 := c_delim);

FUNCTION path RETURN VARCHAR2;

FUNCTION pathlist RETURN dirs_tabtype;

FUNCTION open (file IN VARCHAR2, loc IN VARCHAR2 := NULL) RETURN UTL_FILE.FILE_TYPE;

-- Unit test code in same package

PROCEDURE ut_setup;

PROCEDURE ut_teardown;

PROCEDURE ut_setpath;

END;

</pre>

<p>A few things to notice about this package:</p>

<ul>

<li>

It declares a publicly available collection, fileIO.dirs, in which the

path is deposited. Because it is declared in the package specification,

I can use the utAssert.eqColl procedure (if the collection was hidden in

the package body, I would have to use utAssert.eqCollAPI).

</li>

<li>

The test code is in the same package: the setup,

teardown and test pogram for fileIO.setpath.

</li>

<li>

I declare a second, publicly available collection,

fileIO.ut_dirs, against which I will compare the path that is populated

by fileIO.setpath.

</li>

</ul>

<p>Given that, let's take a look at the implementation of the test program:</p>

<pre>

<a name="useseqcoll"></a>PROCEDURE ut_setpath

BEGIN

/* Populate base collection */

ut_dirs.DELETE;

ut_dirs.EXTEND(2);

ut_dirs(1) := 'c:\temp';

ut_dirs(2) := 'e:\demo';

/* Call setpath to do the work */

setpath ('c:\temp;e:\demo');

utAssert.eqColl (

'Valid double entry',

'fileio.dirs',

'fileio.ut_dirs'

);

END;

</pre>

<p>This program consists of three steps:</p>

<ul>

<li>

Populate the test collection with direct assignments. Call the setPath

program to populate the actual collection (fileIO.dirs). Call the assertion

program to compare the two. Notice that I pass the <i>names</i> of the

collections to the assertion program. utAssert uses dynamic SQL to build

a PL/SQL block "on the fly" that compares values from the collections.

</li>

</ul>

</blockquote>

</body>

</html>

utPLSQL/documentation/src/samepack.html at master · pascal8/utPLSQL · GitHub

Expand file tree

Breadcrumbs

samepack.html

Latest commit

History

Breadcrumbs

samepack.html

File metadata and controls