/docs/dev/testing-metacat.html - Annotate - Metacat - Ecoinformatics Redmine

metacat/docs/dev/testing-metacat.html @ 4725

-            daigle
+<!--
   * sitemaps.html
+  *
   *      Authors: Michael Daigle
   *    Copyright: 2008 Regents of the University of California and the
   *               National Center for Ecological Analysis and Synthesis
   *  For Details: http://www.nceas.ucsb.edu/
   *      Created: 2008 November 4
   *      Version:
   *    File Info: '$ '
+  *
+  *
 -->
 <HTML>
 <HEAD>
 <TITLE>Testing Metacat</TITLE>
-            daigle
+<!-- unfortunately, we have to look for the common css file in the
      user docs directory.  This is because the user docs deploy to
      the top level of the metacat docs on the knb web server -->
 <link rel="stylesheet" type="text/css" href="../user/common.css">
-            daigle
+<link rel="stylesheet" type="text/css" href="./default.css">
 </HEAD>
 <BODY>
   <table width="100%">
     <tr>
       <td class="tablehead" colspan="2"><p class="label">Testing Metacat</p></td>
       <td class="tablehead" colspan="2" align="right">
-            daigle
+        <a href="./metacat-eclipse-project.html">Back</a> | <a href="./index.html">Home</a> |
         <!--a href="add next file here when one exists" -->Next<!-- /a -->
-            daigle
+      </td>
     </tr>
   </table>
   <div class="header1">Table of Contents</div>
   <div class="toc">
     <div class="toc1"><a href="#Intro">About Metacat Testing</a></div>
       <div class="toc2"><a href="#Overview">Overview</a></div>
       <div class="toc2"><a href="#MetacatImplementation">JUnit Implementation in Metacat</a></div>
     <div class="toc1"><a href="#WritingTestCase">Writing a Test Case</a></div>
       <div class="toc2"><a href="#Basics">Basics</a></div>
       <div class="toc2"><a href="#MCTestCase">MCTestCase Base Class</a></div>
       <div class="toc2"><a href="#BestPractices">Best Practices</a></div>
     <div class="toc1"><a href="#RunTests">Running Test Cases</a></div>
       <div class="toc2"><a href="#AntTask">Ant task</a></div>
       <div class="toc2"><a href="#ConfigureMetacat">Configure Metacat For Testing</a></div>
       <div class="toc2"><a href="#RunAllTests">Run All Tests</a></div>
       <div class="toc2"><a href="#RunOneTest">Run One Test</a></div>
       <div class="toc2"><a href="#ViewingOutput">Viewing Test Output</a></div>
-            daigle
+    <div class="toc1"><a href="#TestDbVersions">Testing Different Database Schema Versions</a></div>
-            daigle
+      <div class="toc2"><a href="#Scripts">Scripts to Run</a></div>
       <div class="toc2"><a href="#CheckoutScripts">Get Scripts Via Checkout</a></div>
       <div class="toc2"><a href="#ScriptRepo">Script Repository</a></div>
       <div class="toc2"><a href="#ManuallyRunScripts">Manually Run Scripts</a></div>
     <div class="toc1"><a href="#UserTesting">User Testing</a></div>
       <div class="toc2"><a href="#TestingSkins">Testing Skins</a></div>
-            daigle
+  </div>
   <a name="Intro"></a><div class="header1">About Metacat Testing</div>
   <a name="Overview"></a><div class="header2">Overview</div>
   <p>Metacat uses JUnit tests to test its core functionality.  These tests are
   good for testing the internal workings of an application, but don't test the
   layout and appearance.  JUnit tests are meant to be one tool in the developer's
   test arsinal. If you are not familiar with JUnit, you should search out some
   tutorial documentation online.  One such tutorial is at
   <a href="http://clarkware.com/articles/JUnitPrimer.html"> The Clarkware JUnit primer</a></p>
   <p>Metacat test cases will need to be run on the same server as the Metacat
   instance that you want to test.  Since Metacat and its test cases share the same
   configuration files, there is no way to run the tests remotely.</p>
   <a name="MetacatImplementation"></a><div class="header2">JUnit Implementation in Metacat</div>
   <p>Metacat test cases are located in the code at:
   <div class="code">&lt;workspace&gt;/metacat/test/edu/ucsb/nceas/metacat*/</div>
   There you will find several java files that define JUnit tests.</p>
   <p> Test cases are run via an ant task, and output from the tests appears in
   a build directory.  More on this to follow.</p>
   <a name="WritingTestCase"></a><div class="header1">Writing a Test Case</div>
   <a name="Basics"></a><div class="header2">Basics</div>
   <p>All you need to do to get your JUnit test included into the Metacat test
   suite is to create it in one of the &lt;workspace&gt;/test/edu/ucsb/nceas/metacat*/
   directories.  The ant test tasks will know that it should be run. </p>
   <p> The following methods are required in a test case class:
   <ul>
     <li>public &lt;Constructor&gt;(String name) - The constructor for the test class. </li>
 	<li>public void setUp() - Set up any dependencies for the tests.  This is run before each test case.</li>
 	<li>public void tearDown() - Release an resources used by the test.</li>
 	<li>public static Test suite() - define the test methods that need to be run.</li>
 	<li>public void initialize() - define any global initializations that need to be done.</li>
   </ul>
   You will test for failure using the many assertion methods available.</p>
   <a name="MCTestCase"></a><div class="header2">MCTestCase Base Class</div>
   <p>Metacat test cases extend the MCTestCase base class, which holds common
   methods and variables.  Some of these include:
   <ul>
     <li>SUCCESS/FALURE - boolean variables holding the values for success and failure. </li>
 	<li>metacatUrl, username, password - connection variables used for LDAP connectivity</li>
 	<li>readDocumentIdWhichEqualsDoc() - method to read a document from Metacat server.</li>
 	<li>debug() - method to display debug output to standard error.</li>
   </ul>
   These are just a few examples to give you an idea of what is in MCTestCase.
   </p>
   <a name="BestPractices"></a><div class="header2">Best Practices</div>
   <p>The following are a few best practices when writing test cases:
   <ul>
     <li>Extend MCTestCase - Although strictly speaking, it is possible to bypass MCTestCase
     and just extend the JUnit TestCase class, you should not do so.   You should always
     extend the MCTestCase class.</li>
     <li>Extend Multiple Test Methods - Try to strike a balance between the number of test
     methods and the size of each test.  If a test method starts to get huge, you might see
     if you can break it down into mulitple tests based on functionality.  If the number of
     tests in the test suite starts to get large, you might see if it makes sense to
     separate them out into different test classes.</li>
 	<li>Use assertion message - Most assertion methods have an alternate implementation that
 	includes a message parameter.  This message will be shown if the assertion fails.  You
 	should use this version of the assertion method.</li>
 	<li>debug() - You should use the debug() method available in the MCTestCase class to
 	display debug output as opposed to System.err.println().  The test configuration will
 	allow you to turn off debug output when you use the debug() method.</li>
   </ul>
   <a name="RunTests"></a><div class="header1">Running Test Cases</div>
   <a name="AntTask"></a><div class="header2">Ant task</div>
   <p>As we discussed earlier, the test cases run from within ant tasks.  There is a
   task to run all tests and a task to run individual tests. </p>
   <p>You will need to have ant installed on your system.  For downloads and instructions,
   visit the <a href="http://ant.apache.org/">Apache Ant site</a>.
   </p>
   <a name="ConfigureMetacat"></a><div class="header2">Configure Metacat For Testing</div>
   <p>The test cases will look at the server's metacat properties file for configuration,
   so there are two places that need to be configured.</p>
   <p>First, you need to edit the configuration file at:
   <div class="code">&lt;workspace&gt;/metacat/test/test.properties</div>
   This should only hold one property: metacat.contextDir.  This should point to
   the context directory for the metacat server you are testing.  For example:
   <div class="code">metacat.contextDir=/usr/share/tomcat5.5/webapps/knb</div>
   The test classes will use this to determine where to look for the server
   metacat.properties file.</p>
   <p>the remainder of the configuration needs to happen in the actual server's
   metacat.properties file located at:
   <div class="code">&lt;workspace&gt;/metacat/lib/metacat.properties</div>
-            daigle
+  You will need to verify that all test.* properties are set correctly:
-            daigle
+  <ul>
     <li>test.printdebug - true if you want debug output, false otherwise </li>
     <li>test.metacatUrl - the url for the metacat servlet (i.e. http://localhost:8080/knb/metacat)</li>
     <li>test.contextUrl - the url for the metacat web service (i.e. http://localhost:8080/knb)</li>
     <li>test.metacatDeployDir - the directory where metacat is physically deployed (i.e. /usr/local/tomcat/webapps/knb)</li>
     <li>test.mcUser - the first metacat test user ("uid=kepler,o=unaffiliated,dc=ecoinformatics,dc=org" should be fine)</li>
     <li>test.mcPassword - the first metacat test password ("kepler" should be fine)</li>
     <li>test.mcAnotherUser - the second metacat test user.  This user must be a member of the knb-usr
         group in ldap. ("uid=test,o=NCEAS,dc=ecoinformatics,dc=org" should be fine)</li>
     <li>test.mcAnotherPassword - the second metacat test password ("test" should be fine)</li>
     <li>test.piscoUser - the pisco test user ("uid=piscotest,o=PISCO,dc=ecoinformatics,dc=org" should be fine)</li>
     <li>test.piscoPassword - the pisco test password ("testPW" should be fine)</li>
     <li>test.lterUser - the lter test user ("uid=tmonkey,o=LTER,dc=ecoinformatics,dc=org" should be fine)</li>
     <li>test.lterPassword - the lter test password ("T3$tusr" should be fine)</li>
     <li>test.testProperty - a property to verify that we can read properties (leave as "testing")</li>
   </ul>
   </p>
   <p>Note that none of the test users should also be administrative users.  This will mess up
   the access tests since some document modifications will succeed when we expect them to fail.</p>
   <p>Once this is done, you will need to rebuild and redeploy the Metacat server.  Note that
   changing these properties does nothing to change the way the Metacat server runs.  Rebuilding
   and redeploying merely makes the test properties available to the JUnit tests.</p>
   <a name="RunAllTests"></a><div class="header2">Run All Tests</div>
   <p>To run all tests, go to the &lt;workspace&gt;/metacat directory and type</p>
   <div class="code">ant clean test</div>
   You will see a line to standard output summarizing each test result.
   </p>
   <a name="RunOneTest"></a><div class="header2">Run One Test</div>
   <p>To run one test, go to the &lt;workspace&gt;/metacat directory and type</p>
   <div class="code">ant clean runonetest -Dtesttorun=&lt;test_name&gt;</div>
   Where &lt;test_name&gt; is the name of the JUnit test class (without .java on
   the end).  You will see debug information print to standard error.
   </p>
   <a name="ViewingOutput"></a><div class="header2">Viewing Test Output</div>
   <p>Regardless of whether you ran one test or all tests, you will see output in
   the Metacat build directory in your code at:
   <div class="code">&lt;workspace&gt;/metacat/build</div>
   There will be one output file for each test class.  The files will look like
   <div class="code">TEST-edu.ucsb.nceas.&lt;test_dir&gt;.&lt;test_name&gt;.txt</div>
   where &lt;test_dir&gt; is the metacat* directory where the test lives and
   &lt;test_name&gt; is the name of the JUnit test class. These output files will have
   all standard error and standard out output as well as information on assertion
   failures in the event of a failed test.
   </p>
             daigle
   <a name="TestDbVersions"></a><div class="header1">Testing Different Database Schema Versions</div>
   <p>Now and again it is necessary to restore your test database to an older schema version
   either because you need to test upgrade functionality, or you need to test backwords
   compatibility of code.  This section describes how to get your db schema to an older
   version.
-            daigle
+  <a name="Scripts"></a><div class="header2">Scripts to Run</div>
-            daigle
+  <p>It is assumed that you have an empty metacat database up and running with a
   metacat user.
   <p>There are two types of scripts that need to be run in order to create a Metacat
   schema:</p>
   <ul>
   <li>xmltables-&lt;dbtype&gt;.sql - where &lt;dbtype&gt; is either oracle or postgres
   depending on what type of database you are running against.  This script creates the
   necessary tables for Metacat.</li>
   <li>loaddtdschema-&lt;dbtype&gt;.sql - where &lt;dbtype&gt; is either oracle or postgres
   depending on what type of database you are running against.  This script creates the
   necessary seed data for Metacat.</li>
   </ul>
-            daigle
+  <a name="CheckoutScripts"></a><div class="header2">Get Scripts Via Checkout</div>
-            daigle
+  <p>One way to get the scripts you need is to check out the release tag for the version
   of metacat that you want to install.  You can then run the two scripts shown above to
   create your database.</p>
-            daigle
+  <a name="ScriptRepo"></a><div class="header2">Script Repository</div>
-            daigle
+  <p>For convenience, the scripts to create each version have been extracted and
   checked into:</p>
     <div class="code">&lt;metacat_code&gt;/src/scripts/metacat-db-versions</div>
   <p>The files look like:</p>
   <ul>
   <li>&lt;version&gt;_xmltables-&lt;dbtype&gt;.sql - where &lt;version&gt; is the version
   of the schema that you want to create and &lt;dbtype&gt; is either oracle or postgres
   depending on what type of database you are running against.  This script creates the
   necessary tables for Metacat.</li>
   <li>&lt;version&gt;_loaddtdschema-&lt;dbtype&gt;.sql - where &lt;version&gt; is the version
   of the schema that you want to create and &lt;dbtype&gt; is either oracle or postgres
   depending on what type of database you are running against.  This script creates the
   necessary seed data for Metacat.</li>
   <li>&lt;version&gt;_cleanall-&lt;dbtype&gt;.sql - where &lt;version&gt; is the version
   of the schema that you want to create and &lt;dbtype&gt; is either oracle or postgres
   depending on what type of database you are running against. This is a convenience script
   to clean out the changes for that version.</li>
   </ul>
-            daigle
+  <a name="ManuallyRunScripts"></a><div class="header2">Manually Run Scripts</div>
-            daigle
+  <p>For instructions on running database scripts manually, please refer to:
   <a href="../user/run-db-scripts.html">how to run database scripts</a></p>
             daigle
-            daigle
+  <a name="UserTesting"></a><div class="header1">User Testing</div>
   <p>The following sections describe some basic end user testing to stress
   code that might not get tested by unit testing.</p>
   <a name="TestingSkins"></a><div class="header2">Testing Skins</div>
   <p>For each Skin:</p>
   <ul>
   <li>View main skin page by going to:
     <div class="code">http://dev.nceas.ucsb.edu/knb/style/skins/&lt;skin_name&gt;</div>
   for each skin, where &lt;skin_name&gt; is in:
     <div class="code">default, nceas, esa, knb, kepler, lter, ltss, obfs, nrs, sanparks, saeon</div>
   </li>
   <li>Test logging in.  Where applicable (available on the skin) log in using an LDAP account.</li>
   <li>Test Basic searching
      <ul>
      <li>Do a basic search with nothing in the search field.  Should return all docs.</li>
      <li>Select a distinct word in the title of a doc.  Go back to main page and search for
      that word.</li>
      <li>Select the link to the doc and open the metadata.  Choose a distinct word from a
      field that is not Title, Abstract, Keywords or Personnel.  Go back to the main page and
      search all fields (if applicable)</li>
      </ul>
   </li>
   <li>Test Advanced Searching
      <ul>
      <li>On the main page, choose advanced search (if applicable)</li>
      <li>Test a variety of different search criteria</li>
      </ul>
   </li>
   <li>Test Registry (if applicable)
      <ul>
      <li>Create a new account</li>
      <li>use the "forgot your password" link</li>
      <li>change your password</li>
      </ul>
   </li>
   <li>Test Viewing Document
      <ul>
      <li>Use your search to find a document</li>
      <li>Choose the link to a document - you should see document details
      <li>In a separate browser, try the shortcut to the doc:
        <div class="code">http://dev.nceas.ucsb.edu/knb/metacat/&lt;doc_id&gt;/&lt;skin_name&gt;</div>
      You should see the same results as going to the doc via search.</li>
      </ul>
   </li>
   <li>Download Metadata
      <ul>
      <li>Choose the metadata download</li>
      <li>Save the file</li>
      <li>view contents for basic validity (contents exist, etc)</li>
      </ul>
   </li>
   <li>Downlaod Data
      <ul>
      <li>Choose the data download</li>
      <li>view the data for basic validity (contents exist, etc)</li>
      </ul>
   </li>
   <li>View Data Table
      <ul>
      <li>Find a document with a data table</li>
      <li>Choose to view the data table</li>
      <li>view the data table for basic validity (contents exist, etc)</li>
      </ul>
   </li>
-            daigle
+  <br>
-            daigle
+  <a href="./metacat-eclipse-project.html">Back</a> | <a href="./index.html">Home</a> |
   <!--a href="add next file here when one exists" -->Next<!-- /a -->
             daigle
 </BODY>
 </HTML>

Project

General

Profile

Metacat