| 10:40:47 | pimpaa: | hello all |
| 15:10:28 | landonf: | Howdy |
| 18:49:00 | landonf: | A possibly odd question -- how do you good people test software written to expect populated data sets? |
| 18:53:49 | pramsey: | hm? |
| 18:53:53 | pramsey: | re-phrase |
| 18:56:49 | CIA-6: | pramsey * r2782 /branches/1.3/ ( 4 files in 2 dirs ): Fix for DBF files with deleted records. ( #29 ) |
| 18:57:53 | CIA-6: | pramsey * r2783 /trunk/ ( 4 files in 2 dirs ): Fix for DBF files with deleted records. ( #29 ) |
| 19:07:42 | landonf: | pramsey: I'm wondering how to sanely unit test something that relies on postgis. |
| 19:08:52 | mloskot: | landonf: you need to prepare test cases with test data |
| 19:09:22 | landonf: | And reset the database between runs? |
| 19:09:22 | mloskot: | for instance, 1 case does INSERT |
| 19:09:26 | mloskot: | 2 case does SELECT |
| 19:09:49 | mloskot: | and you compare what was written against to what was querried |
| 19:10:03 | mloskot: | landonf: yes, cleanup after every tests run is needed |
| 19:10:31 | mloskot: | landonf: every run should be isolated from any previous and next |
| 19:10:49 | landonf: | Have you written glue to initialize a postgres db through each run? |
| 19:11:43 | mloskot: | it depends on particular testing approach |
| 19:11:58 | mloskot: | some prefer to have every test case isolated from others |
| 19:12:12 | mloskot: | so they do not have to worry about tests order in which they are executed |
| 19:12:26 | mloskot: | ie. first test case that inserts, then test case that selects |
| 19:12:50 | mloskot: | Another approach is to have test cases ordered in predictible chain |
| 19:12:53 | mloskot: | 1. insert data |
| 19:12:56 | mloskot: | 2. select data |
| 19:13:13 | mloskot: | 3. select data in different way |
| 19:13:17 | landonf: | Are you aware of a solution or examples that handle dropping the database, re-initializing the DDL, and re-inserting test data? |
| 19:13:21 | mloskot: | 4. delete data |
| 19:13:22 | mloskot: | etc. |
| 19:13:48 | mloskot: | one of may around the Web |
| 19:13:48 | mloskot: | http://trac.osgeo.org/gdal/browser/trunk/autotest/ogr/ogr_pg.py |
| 19:13:50 | sigq: | Title: /trunk/autotest/ogr/ogr_pg.py - GDAL - Trac ( at trac.osgeo.org ) |
| 19:15:03 | mloskot: | landonf: I'm quite sure there is no unification, because it depends on particular needs |
| 19:15:30 | landonf: | *nod* |
| 19:15:31 | landonf: | gdaltest.pg_ds.ExecuteSQL( 'DROP SCHEMA \"AutoTest-schema\" CASCADE' ) |
| 19:15:36 | mloskot: | IOW, generally it's not a problem initialize, etc. |
| 19:15:41 | landonf: | Using a special SCHEMA is a handy idea |
| 19:15:43 | landonf: | Thanks |
| 19:15:49 | mloskot: | right, just use a bunch of SQL cmds at the end |
| 19:16:19 | mloskot: | Some may want to test against number of databases |
| 19:16:24 | mloskot: | where some instances are read-only |
| 19:16:28 | mloskot: | and other are for writing data |
| 19:16:36 | mloskot: | may approaches are possible |
| 19:16:40 | mloskot: | and configurations |
| 19:17:16 | mloskot: | It's just important to have test data consistent and constant in longer periods, so you don't have to fix tests too often |
| 19:17:28 | landonf: | *nod* |
| 19:21:40 | landonf: | Thanks, appreciate the links and the info |
| 19:22:18 | mloskot: | more complex example is FDO |
| 19:22:18 | mloskot: | http://trac.osgeo.org/fdo |
| 19:22:19 | sigq: | Title: FDO - Trac ( at trac.osgeo.org ) |
| 19:22:49 | mloskot: | here is test package for one of FDO providers |
| 19:22:49 | mloskot: | http://trac.osgeo.org/fdo/browser/trunk/Providers/GenericRdbms/Src/UnitTest |
| 19:22:50 | sigq: | Title: /trunk/Providers/GenericRdbms/Src/UnitTest - FDO - Trac ( at trac.osgeo.org ) |