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…