appsunit-develop Mailing List for Apps Unit (Page 4)

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Update of /cvsroot/appsunit/web/htdocs/testguide
In directory sc8-pr-cvs11.sourceforge.net:/tmp/cvs-serv27722/web/htdocs/testguide

Added Files:
	AppsUnit Test Guide.html 
Log Message:
Added first draft of the Test Guide.

--- NEW FILE: AppsUnit Test Guide.html ---
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>

  <meta content="text/html; charset=ISO-8859-1" http-equiv="content-type">
  <title>AppsUnit Test Guide</title>

</head>

<body>

<h1 class="western">AppsUnit</h1>

<table class="" style="text-align: left; width: 712px; height: 132px;" border="1" cellpadding="2" cellspacing="2">

  <tbody>

    <tr>

      <td>
      <div>This project is just starting (08-SEP-2006).</div>

      <div>The aim is to create a toolkit that will support unit
testing Oracle
Apps bespoke code.</div>

      <div>There's no need to install anything on the Apps
instances.</div>

      <div><br>
Please refer to the <a href="http://sourceforge.net/projects/appsunit">project home
on SourceForge.net</a> for more info.</div>

      </td>

    </tr>

  </tbody>
</table>

<p style="margin-bottom: 0cm;">Oracle e-business suite
test toolkit</p>

<h1 class="western">Test Guide</h1>

<h2 class="western">Foreword</h2>

<p>Although automation of functional test for ERP software is
becomming common practice, unit testing and test driven development
is less popular.<br>

This project wants to promote unit testing, and
test driven development, in the ERP community. We will do this by

<ul>

  <li>
    <p>showing that it can be done,</p>

  </li>

  <li>
    <p>providing usefull tools to facilitate testing.</p>

  </li>

</ul>

<p>This document describes how you can test your code,</p>

<h2 class="western">Testing views</h2>

<p>When creating database views, the most common failures are
missing
or duplicate records, and wrong data values.</p>

A wrong record count is mostly caused by incorrect joins. If
you
forget to define an outer join, your view will miss records. If you
don't use the propper join conditions, you might get duplicate
records. If you forget the join conditions for one of the tables,
you'll get a lot of wrong records.

<p>You can avoid these mismatches by asserting that your view
contains the correct number of records.<br>

Most of the time there is
one table in the view that is the driving table. It's the core table
of the view. Compare the record count of that table with the record
count of your view.

When creating a view for order lines with additional item and
customer info, the driver could be oe_order_lines_all. It's the
number of order lines in the system that should decide how many rows
your view returns, not the number of items or customers you have.
Your view should return exactly the same record count as table
oe_order_headers_all.

<table border="1" bordercolor="#000000" cellpadding="4" cellspacing="0" width="100%">

  <col width="256*"> <thead> <tr>

    <td valign="top" width="100%">
    <p><u>How to test for missing or extra records in a
view?</u></p>

    <p>Find the table that is the core of your view (the driving
table).<br>

Assert that the record count of the driving table matches the record
count of your view.</p>

    <p><font face="Courier New, monospace">simpleCompare(
&ldquo;select count(*) from oe_order_lines_all&rdquo;,<br>

&ldquo;select count(*) from xx_order_lines_view&rdquo;);</font></p>

    </td>

  </tr>

  </thead>
</table>

<p><br>

<br>

</p>

You can create this test at the very begin of your view design
phase. Then start by creating your basic view:

<p><font face="Courier New, monospace">create view
xx_order_lines_view as <br>

select<br>

line_id <br>

from<br>

oe_order_lines_all<br>

with read only;</font></p>

The tests will pass. You can now safely add extra fields and
tables to the view. Run the tests again. If you forget an outer join,
or create a cardinal join, your tests will fail.

Validating the correctness of a field value in your view is
straightforward. You write a quey that asserts wether your view
returns the value you expect.

If you want to validate the value for the customer, you could
locate an example order line in your application and write down the
customer name (the expectation). Then write a query to verify that
your view returns this customer.

<p><font face="Courier New, monospace">select
count(*) from
xx_order_lines_view where<br>

line_id = 25845<br>

and customer_name
= 'SOURCEFORGE';</font></p>

<table border="1" bordercolor="#000000" cellpadding="4" cellspacing="0" width="100%">

  <col width="256*"> <thead> <tr>

    <td valign="top" width="100%">
    <p><u>How to test for correct field values in a view?</u></p>

    <p>Locate an example that has a known value for the field.<br>

Assert that the view returns this expected value.</p>

    <p><font face="Courier New, monospace">simpleCompare(
&ldquo;select 1 from dual&rdquo;,<br>

&ldquo;select count(*) from xx_order_lines_view where line_id =
23548<br>

and item_description = 'Feature Request'&rdquo;);</font></p>

    </td>

  </tr>

  </thead>
</table>

<p><br>

<br>

</p>

Add regression tests during the lifecycle of your view.
Whenever
you find a wrong value in your view, or when someone raises a bug
against your view, create a test that fails for the given error.

<p style="font-style: normal;">If the error report says
that your view
reports that the order line was not closed, but the application shows
that it's closed, you can create a regression test:</p>

<p style="font-style: normal;"><font face="Courier New, monospace">select
count(*) from xx_order_lines_view where<br>

line_id = 12487 <br>

and
closed_status = 'Y';</font></p>

The test will pass when your bug is resolved. And because you
add
this test to the test suite, this bug will never have a chance of
showing up again.

<table border="1" bordercolor="#000000" cellpadding="4" cellspacing="0" width="100%">

  <col width="256*"> <thead> <tr>

    <td valign="top" width="100%">
    <p><u>How to avoid regression?</u></p>

    <p>Create a regression test for each bug or error reported
for your view.<br>

Add the test to your test suite.</p>

    <p><font face="Courier New, monospace">simpleCompare(
&ldquo;select 0 from dual&rdquo;,<br>

&ldquo;select count(*) from xx_order_lines_view where line_id =
48574<br>

and payment_date &lt; order_date&rdquo;);</font></p>

    </td>

  </tr>

  </thead>
</table>

<p><br>

<br>

</p>

<h2 class="western">Testing functions</h2>

<p>To be written</p>

<h2 class="western">Testing concurrent requests</h2>

<p>To be written</p>

</body>
</html>

appsunit-develop Mailing List for Apps Unit (Page 4)

appsunit-develop — Apps Unit Development list