These four bugs center around the behavour of a 5-step import "wizzzard" (its magic is on pair with Rincewind's
I'm still having a hard time figuring out how to integrate the database aspect with the test. Here's my current thoughts:
I want to develop "abstract" subclasses (one off the Unit tree and one of the Web Tree). (Abstract in quotes since I'm still PHP4) The setup procedure will connect (as a database superuser ) to a database named in the concrete subclass of the new class, checking for an explicit "test" prefix to the dbname or fail. It will then drop all tables from the DB and reload from a SQL file also identified in the constructor, defaulting to a "stock" populated test DB of the identified "DB Type" (I have "Central" and "Per-Event" databases with different schemas). The final step is to drop the connection and reconnect as the user identified in the subclass constructor (ie a normal DB user), failinng if not possible.
It'll also probably off some new assertions
- assertTableInlucdes($tablename, $rows,$expected)
- assertTableDoesNotInlucde($tablename,$rowss)
Code: Select all
$rows = array(array("peopleid"=>1,"firstname"=>"Eric","lastname"=>"Nielsen"));I've thought a lot about providing an assertDatabaseContents($filename) that would loop through textual schema dump file and check explicitly for every roww in every table. Tables not listed in the schema dump would be ignored. Tables listed would have to match exactly, ie equal number of rows and all specified rows included. But I think I've concluded that this would be too brittle and lead to countless "false fails". Testing behavoir of on update/delete rules will have to be done via explicit calls to the two new assertions.
Is this basically what you've been saying, with the modification that I have the luxury/requirement of multiple database and not masquerading a database inside a prefixed table approach?