Manifesto:

• create a database for testing that is easily created, is pre-populated with minimal configuration, whose tables are associated correctly, is quickly rolled back between tests, and is correct, every time.
• should have a way of doing it all by hand but should default to populating the db for you.
  ToDo:
• Done - get it working with sqlite3
• Done - read in all models
• record attribute information in a test db
  • need a method to open the database
  • need a method to create/write to the database table generic data
• record association information
  • for each association (habtm, has_many, has_one, belongs_to, etc.),
    • if it uses a join table, or is owned/owns another model
      • find the join table, or child table
      • make sure id's and foreign keys line up.
• write it to the database with a function call?
• reset the database with a function call?
• drop the database with a function call?

Discussion: Maybe I can use populator and faker to add data to the database...

There are definitely a couple of different ways I can go with this: one, I can create the factory files via meta programming, and have them loaded as usual using begin-end block in env.rb (slow but db agnostic) two, I can create the database from scratch and roll it back somehow whenever you tell it to roll back (faster but need to know the database) three, I can somehow get into the model instances that are created in the development environment...not sure how to do this from 'RAILS_ENV=test' four, I can use ActiveRecord::Base class methods to record attributes and associations of the db tables (i.e. reflect_on_association), and then create the test database on the fly whenever needed. (this sounds like the best solution, so I can completely forget about factory_girl, and I am not reinventing the activerecord wheel by trying to parse model files, yet I am properly recording my associations, creating the test database correctly, and reusing it as many times as I want) (maybe there's a formal rollback method for the test database connection, I think I saw one...) (lets just hope I can use all of the AR class methods from the test env when needed. Update: yes!!! Even without tables created and filled out w/AR, I can use class methods to study/use associations and attributes...fantastic)

• May want to read from the models... that way, we can stay db agnostic...
  • can we use reflect_on_association??? is this too hard?
  • how can we structure this so that it makes sense? are we replicating effort?
  • we could require the model files, create instances in memory without writing to the db, then when we have to, write to the test db.
  • want to have it in memory the way you want it, and write to the db at each iteration instead of recreating the database manually.
  • we should stay away from the database itself until we write it... to the test db at each interval
  • get it working with cucumber first...
  • construct the data automatically, minimal effort to construct factories yall...
  • the instances should be created with restrictions in mind
  • should Steamer be of type ActiveRecord::Base to take advantage of reflect on association?
• read from database
• write it to factory directory in rb files
• instantiate it correctly in env.rb or wherever the factories are normally created (cucumber, rspec, etc.)
• get associations made correctly using model associations
• test out the factories
• write some specs
• we want to have a version of the database that we can go back to...