FarragoCheckinAcceptance

From Eigenpedia

Before submitting a change to Farrago, developers are responsible for running ant test, which is the command to run the checkin acceptance test suite. The table below explains the checks enforced by this suite and what to do when you violate them.

Check Enforced	Violation Report Location	How to Resolve a Violation
ant createCatalog and ant buildExamples must succeed	ant output; possibly initsql/SomeScript.log file	Fix the offending code (or build.xml if you have made changes to the build process). If the failure is one of the SQL scripts under initsql, see below on SQL diff-based tests.
All enabled JUnit tests implemented as Java code must pass	ant output tells which tests failed; for details, see testlog/TEST-corresponding.ClassName.txt	If the failure is due to broken functional code, fix it. If the failure is due to bad test logic exposed by your changes, fix the test. If your changes caused an existing bug to become visible to an existing test (i.e. the bug was previously masked by some other flaw which you fixed), and you can't fix the existing bug yet, make sure that <a class="wiki_link" href="/BugDatabase">bug is logged</a>, and then disable the test. Record the disabled test in the bug log as a reminder to re-enable it once the bug is fixed, and also add a cross-reference (as a code comment) from the test to the bug database. Our convention for disabling JUnit tests is to prefix the test method name with an underscore.
All enabled JUnit tests implemented as SQL diff-based scripts must pass	ant output will say FarragoSqlTest failed;for list of failed tests, see testlog/TEST-net.sf.farrago.test.FarragoSqlTest.txt; for details, diff unitsql/.../someFile.log or regressionsql/.../someFile.log against corresponding .ref file; script /open/util/bin/difs/ can be used to get a full report automatically	Same rules as Java for broken code, bad test logic, and existing bug exposure. Fixing the test may be as simple as updating the content of the expected .ref file, particularly in the case of the cosmetic changes which plague diff-based testing. Another possibility is to add a diff mask to method runTest in FarragoSqlTest.java; use sparingly. To disable an SQL test, you have to comment out the offending statements, re-run, and then update the .ref file.
Test execution must leave the catalog in the same state as before tests started.	ant output "catalog differs from clean state"; see dump files in testlog/CatalogLeak	Track down which test polluted the catalog. Run ant exportCatalog before suspect test, and ant compareCatalogExport after test. For dangling objects, fix functional code (e.g. make sure dangling object has a parent or gets deleted explicitly). For top-level objects, add to inner class Cleanup of class FarragoTestCase.
ant macker must pass	ant output	Fix dependency violation by removing offending imports and reworking your code accordingly. If you have added a new package, update src/macker.xml. Before updating macker's rules for what you think is a legitimate dependency change, always get architectural review first.
ant checkSourceFilePreambles must pass	ant output	Fix source file header as directed by ant output.
ant checkJavadoc must pass	ant output; javadoc-complaints.log	Fix Javadoc as directed by javadoc-complaints.log.