On Tue, Mar 11, 2008 at 02:54:32PM -0400, John Elrick wrote: > [EMAIL PROTECTED] wrote: > > Our solution to this problem is that we allow the test script > > to monkey with the state of the Pseudo-Random Number Generator > > (PRNG) that SQLite uses to generate random rowids. On a test > > build, we have special APIs that will save the current state > > of the PRNG and that will restore the state of the PRNG to its > > most recently saved state. > > > > There is a fairly common pattern where the random number generator is > passed into the system under test as an abstraction. That permits one > to substitute any type of mock generator one would like, including one > accessing an array of specifically picked numbers. Easier to do in > languages which either support interfaces or dynamic typing, although I > guess you could do it in C as a callback function.
Slightly OT: The current SQLite3 test code base makes use of internal interfaces, which means you can't necessarily test the bits that you want to install. It'd be nice to be able to test the bits actually installed. No, I don't have useful suggestions yet as to how to achieve that. And yes, the SQLite3 testsuite is impressive. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
