From Ingres Community Wiki

Ingres SEP Scripting Best Practices

1. Never do in one stage what you can do in many stages. Many short result canons are better than one long canon. Debugging problems will be easier.
2. Never use a front-end tool when a command line tool exists. The canons are more manageable using command line tools within SEP. That is unless a front-end tool is what you are testing.
3. Use built in commands in SEP whenever possible.
4. Ensure the tests are portable.
5. Use ignore canons <<~>> sparingly.
6. Always include “order by” clauses when a select query pulls back more than one row.
7. Create all tests as “testenv” and use “qasetuser ingres” to change ownership within a test.
8. Do not write tests that will always diff, realize when unpredictable results will always occur and find another way.
9. A test should not be dependent on other tests. It should be able to be run any number of times without DIFFING on subsequent runs. Clear up at the start of a test with SQL drop statements.
10. Name database objects after the test. They should all be identifiable for where they came from to avoid trampling other tests or making it impossible to know what can be safely deleted.
11. Use fill files for SQL statements sparingly if at all. Just fold the SQL statements into the test during the TM session so if anything goes wrong, you can see what is going on and what commands are being executed.
12. Leave nothing behind, i.e. ensure any temporary files are cleaned up when the test completes. Compiling a program will create *.c, *.o, *.obj, *.exe so these need “delete” statements at the end of the test to clean them up. SEP will only automatically cleanup a file that was created as a “fill” file.
13. Complete the header comments.
14. Include a proper/current copyright statement.
15. Use one of the predefined databases whenever possible.
16. Use the SEPPARAMDB variable in the test.
17. Use existing SEP tests and suites for guidance on how to write new tests. Avoid reinventing the wheel.
18. Use data already in the database, i.e. system catalogs - when all that is needed is "some data" for a read-only test.