On Mar 21, 1:04 pm, Nels Nelson <[email protected]> wrote: > On Mar 21, 1:21 pm, Jeremy Evans <[email protected]> wrote: > > > Looking at your gist, the easiest way to handle things would be to > > define the schema correctly the first time, define your models, then > > rebuild the schema for each test:https://gist.github.com/879901 > > Thanks Jeremy, that is a good idea. Unfortunately, this would force > me to apply plugins and assign datasets _outside_ the setup/tear-down > routines _every time_ the setup/tear-down routines are invoked. See > the comment in this gist, and particularly, please note lines 18-20: > > https://gist.github.com/880051
Under no circumstances should you be using models inside of your migrations. Doing so leads to brittle migrations, that can break later if you modify the model class. > Not only does this cause needless code duplication within the script, > but it runs contrary to my (confused?) opinion that plugins and > dataset assignments are setup/tear-down activities by definition, and > therefore should be part of those routines. Such code duplication can easily be fixed by having a global method/ proc that is called by both places, or maybe just calling TestSomeDatabaseRoutines.new.setup once before defining the models. There's no reason you must define your model classes before defining the TestSomeDatabaseRoutines class, just before instantiating it for the first time. > Furthermore, if I let myself define the setup/tear-down routine in two > places, I might cry. ;-) > > > If your are using a database that supports transactional schema > > modifications, such as PostgreSQL, you can just run each test case > > inside a database transaction. > > This is another very good idea. I _am_ using PostgreSQL, and this > would be a perfectly reasonable thing to do... but I can imagine that > the limit this would place on the way I could exercise the data models > would be overly restrictive for my purposes. I would definitely use transactions for all tests. If you find it causes any problems, you can always exempt those specific tests from using a transaction. I think you'll find you don't have to do that often, if ever. > I really do appreciate the time you are taking to reply to my > questions, Jeremy. However, I fear that I am just going to have to > somehow redefine the Sequel::Model(source) method from model.rb so > that I can avoid pestering you with this triviality any further. I would advise against that, but it's your app. :) For most apps, my recommendation would be to not have your test suite use migrations at all. Instead, migrate your test database the same way you migrate your development and production databases. Then you can just run your test suite command after your migration command, and have it use transactions or at worst clear the database tables manually (delete/truncate). Unless your app's production usage makes database schema changes like adding tables/columns at runtime (evil!), there's no reason to teardown and rebuild the entire database for each test. If you must rebuild the test database for each test, I would rebuild the model classes as well. I.e., use Object.send(:remove_const, :ModelClass) for each model class you are defining. You can do this without the class definition in method body error by adding a proc to the top level that defines the classes (removing them first if they are already defined) and just calling it from the method. You may want to look at the Sequel integration tests, which do rebuilt tables and models at runtime: https://github.com/jeremyevans/sequel/blob/master/spec/integration/model_test.rb Also, from the code you've shown, you probably don't want to use migrations. You can just call the database schema methods directly on the database. Again, the Sequel integration tests are good examples of this. Jeremy -- You received this message because you are subscribed to the Google Groups "sequel-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/sequel-talk?hl=en.
