tests/README

   1 * REGRESSION TEST SUITE GOALS
   2
   3 The intent of this test suite is to provide sufficient coverage for
   4 the system to support the following:
   5
   6 ** Refactoring and Redesign of particular subsystems
   7
   8 Refactoring and redesign efforts are normally restricted to a single
   9 subsystem, or perhaps to interdependent subsystems.  In such cases, a
  10 set of regression tests which excercise the existing interface of the
  11 rest of USQL to the changing subsystems should be in place and passing
  12 before the coding starts.
  13
  14 ** Ensuring portability and Supporting new ports.
  15
  16 The more coverage the test suite provides the easier portability is to
  17 maintain, particularly if we have instances of the test suite running
  18 against the head on the supporting lisp environment/OS/hardware/DBMS
  19 combinations.  Since no individual within the project has the ability
  20 to run all of those combinations themselves, we are dependent upon some
  21 informal coordination between the mintainers of the various ports.
  22
  23 ** Adding new RDBMS backends
  24
  25 The entire USQL DBMS interface needs to be excercised by the test
  26 suite, such that a new RDBMS backend that passes all the tests can be
  27 reasonably assured of working with the USQL layers above that.  These
  28 tests should also serve as impromptu documentation for the details of
  29 that interface and what it expects frothe RDBMS driver layers.
  30
  31 ** Bug identification and QA
  32
  33 As new bugs are identified, they should have a regression test written
  34 which excercises them. This is to ensue that we donot start
  35 backtracking. These tests by theselves are also very valuable for
  36 developers, so even if you cannot fix a bug yourself, providing a
  37 testto excercise it greatly reduces the amount of timea developer must
  38 spend finding the bug prior to fixing it.
  39
  40
  41 * TEST DESIGN ISSUES
  42
  43 ** Multiple RDBMS Issues
  44
  45 USQL supports several RDBMS backends, and it should be possible to run
  46 every test against all of them.  However, there are some features
  47 which we want tests for but which are not implemented on several of
  48 the backends.
  49
  50 ** Test Hygiene
  51
  52 Tests should be able to be run multiple times against the same
  53 database.  It is also important that they clean up after themselves
  54 when they create tables, sequences or other pesistent entities in the
  55 RDBMS backends, because often there are limits to the number of those
  56 thatcan exist at one time, and it also makes debuging thru the SQL
  57 monitors difficult when there aretons of unused tables lying around.
  58
  59 If test need to load large datasets, they should have a mechanism to
  60 ensure the dataset is loaded just once, and not with every test run.
  61
  62 Lastly, because there are various idiosyncracies with RDBMSs, please
  63 ensure that you run the entire test suite once when you write your
  64 tests, to ensure that your test does not leave some state behind which
  65 causes other tests to fail.
  66
  67 ** Test Run Configuration
  68
  69 The file test-init.lisp defines several variables which can be used to
  70 control the connection dictionary of the database against which tests
  71 will be run.
  72
  73
  74 * DATABASE CONNECTIONS/LIFECYCLE
  75
  76 ** CreateDB
  77    *** Without existing DB
  78    *** With existing DB and use old
  79    *** With existing DB and use new
  80    *** Error if existing DB
  81
  82 ** Data Definition
  83   *** Create Tables/Sequences/Indexes -- Should cover creation of
  84       tables with all supported types of fields.
  85   *** Delete Tables/Sequences/Indexes
  86   *** Inspection of Tables and attributes, including types
  87
  88 ** Data Manipulation
  89   *** Update
  90   *** Insert
  91   *** Delete
  92   *** Query
  93
  94 ** Functional Interface
  95   *** Creation/Modification of SQL expressions
  96   *** Querying
  97
  98 ** Embedded SQL syntax
  99   *** Excercise all sql operators
 100
 101 ** Object Interface
 102   *** View class definition
 103   *** Object creation/manipulation/deletion
 104   *** Inter-object Relations
 105
 106 ** Editing Contexts
 107   *** Object Create/Modification/Deletion in a context -- partly covered already
 108   *** Interaction of multiple contexts
 109   *** Schema manipulation within a context
 110   *** Rollback and error handling within a context