Closed shippy closed 9 years ago
I'm all about moving from fixtures to factories. We can use the fixtures to inspire our factories :)
what is this architectureee
UserObserver
is a model dedicated to creating a user config after a user is created, with stubbed out hard-coded data?
soo we don't need a factory for user config because it's auto-created
Same is true for DepartmentsObserver
I suppose fixtures would side-step this by not having the "create" method called, just loading into the database.
ooooh this is terrible but could we use our anonymized database as a stopgap to run tests for now?
That sounds like a pretty bad stopgap, and the last thing we should be building tests around IMO
My first goal is to be able to run a test once that helps with development speed, like automating creating and viewing a time slot. This will help get devs trained & excited about the testing process.
My second goal is for the testing suite to test things long-term - anything we do to meet the first goal supports this goal completely.
Still a terrible idea? lol maybe yeah
I know developing fixtures will be sort of annoying and take awhile, but I think it's much better in the medium- and long-terms
Since these tests will increase our development speed (and make the app maintainable!), do you think we should we stop working on other tasks until we get fixtures down?
I think we should finish everything in this milestone first, then work on fixtures.
We have some basic factories now! I even refactored them a little bit so they're not totally embarrassing :D
on branch 367_integration_testing
We ended up orienting towards factories, so we should probably delete fixtures instead. Closing.
Currently, the RSpec suite (#281) runs on fixtures. Whether or not this is an antipattern remains a matter of taste. Since we have fixtures, not factories, fixing them is worth investigating.
(And if fixing fixtures is too taxing, migrating to factories will make #325 easier.)