The approach using transactions would be great, but I'm afraid that it wouldn't work if the system under test uses transactions internally. I could switch from SQLite to a DBMS which supports nested transactions, but then I would lost the speed of an in-memory database.
On 18 Sty, 21:01, [email protected] wrote: > u want to simulate what sqlalchemy is doing? > i'd put some layer facading between the app and the sqlalchemy, then > replace sqlalchemy with something else. that'll need a) test that > assures the two facades behave equivalent, and b) the app tests > should not rely on any partcular persistency-flavour. This facade would be a kind of Data Access Layer I mentioned. It seems that this is the most reasonable solution. > > another unrelated way is to have presetup sqlite db files, on which to > run the tests (instead of buiding db from scratch each time). this > may or may not be faster, depends what is longer - the initial > insertions or the actual tests. I've tried this. The file-based SQLite database is much slower than the in-memory one and eventually the total time is even worse. Adam --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
