On 11/4/05, Ian Bicking <[EMAIL PROTECTED]> wrote: > I wouldn't reuse SQLObject's own test code. It was written before > ConnectionHub, so has some added complexity there, and also has some > optimizations that make things more complex and I suspect don't actually > make the tests run any faster.
Done! (Man, it's so easy to not do something. :) > I think creating test data is best done just with Python statements; > fancy config files or YAML or whatever isn't going to be much more > compact. But routines to perhaps dump and reload to CSV or something > might be nice -- e.g., fiddle with a blank database with catwalk, then > dump the results, giving you something interesting to test against. The > results are hard to edit, though, especially relations. I agree that moving things out to independent files rarely has the benefits people want. Good point, though about using catwalk and export/import. > One interesting thing that Rails does is, when possible, run the test in > a transaction. When the test is through, roll the transaction back and > the database is at its original state. This is much faster than > reseting all the data for each test. Hmm. This is good, except sqlite doesn't support nested transactions. So, if the code that you're testing does a commit, you can't roll back. Of course, if the framework is managing the transactions at the request boundaries, then it's easy to work around that for testing purposes. Kevin
