Dave Aronson wrote: > On Tue, Jul 13, 2010 at 09:19, Marnen Laibow-Koser > <[email protected]> wrote: >>> >>> Good ideal to strive for... but not absolutely necessary all the time. >> >> Wrong! If the test has any potential of touching the database, it is >> *absolutely necessary all the time* to reset the DB to a known state. >> Usuallythat means clearing it. > > Ah, there's the key: "Usually". So, the line is at least a smidgen > never-ward of always. I'll grant you at least a few "nines" of > always-ness, but it's still not 100%. Except by rounding. :-)
Setting the database to a known state must be 100%. Clearing (as opposed to resetting to known constant data) may be only 99.999...%. > > *If* a given database (or table or set of tables) is absolutely > constant, so that it will not be added to or subtracted from during > the course of any test, only referenced, as seems to be the case in > FF's situation, But there is no way to guarantee that the "constant" table is in fact constant, unless we get into using permissions in the DB (which will probably cause more problems than they solve). The values in it could get accidentally changed at any time. > then it is (IMVHO) sufficient to only clear-and-load > it at the start of the entire suite, rather than incur the penalties > of doing so on every test. Perhaps that could even be enforced (at > least for the duration of the tests) with some triggers. That is only true insofar as the table can be guaranteed read-only, which it usually can't be. Transactional tests will probably work here, though. > > On the other claw, if there aren't a large number of tests, or he can > make do with a much smaller (i.e., faster to clear and load) database, The number of tests has nothing to do with it. I routinely run fairly large test suites with a small database (by using factories, so that each test only has a few records in the DB while it runs). > or the database clearing and loading can be done by a much faster > mechanism (such as pointing a symlink to a different set of files?), What, set up multiple test databases? Yuck. (Of course, it's entirely possible that the DBMS is doing this and abstracting it anyway.) > the point may be moot.... > > -Dave Best, -- Marnen Laibow-Koser http://www.marnen.org [email protected] -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" 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/rubyonrails-talk?hl=en.
