Hey Josh, Thanks for the answer, I'll give the factory boy a shot. I just don't like to put code that populate fields in the setup function (especially when using nested relations). It's just a lot of code to achieve it and lost time to me. (I normally use the current test database and dump relevant data (and sometimes remove some)). That is way more quicker than creating user, user profile, and whatsoever I need to actually test my model/view. I also only run just the unit tests I need, which is most of the time less than 30. I just run all when I'm done and want to commit my changes or I'll let Jenkins worry about that (and I really don't care if jenkins takes 5 or 15 minutes, although I do see the point for really big projects).
On Tuesday, September 2, 2014 8:34:17 PM UTC+2, Matteo Kloiber wrote: > > Hello, > I thought it might be pretty helpful if there was a load_fixtures > annotation that loads fixture for a specific test method > in TransactionTestCase. On some occasions, it might be pretty hard to test > a model/view that uses only one or a few fixtures that are always the same. > Here are some occasions, where it might be helpful to have these > annotation. > > - I may want to test when the database is empty. > - It might be necessary to have a fixture with a lot of data (and I mean > >1000). Loading some much data for every testcase is highly ineffective > because it takes a time to clean up and load the data again. > > I’m sure there are more occasions when this might be helpful. > Here is what the implementation might look like: > > @load_fixtures(*fixtures, flush=False) > > fixtures are the fixtures to load (just like the instance variable). flush > means whether the old data (i.e. the data that was loaded by the instance > variable) should be flushed. `fixtures` should be optional so that flush > can sand-alone. That allows me to have an empty database (this could be > useful when only a very limited amount of tests need an empty database > while the other tests need the default fixtures). > It shouldn’t replace the fixtures instance variable, it should just be an > addition. > > I know, it can be implemented and doesn’t require changes in the core but > it would be super helpful if it came out if the box. The flush parameter > could be optimized when implementing directly in the core > (i.e. TransactionTestCase). Loading default fixtures (the ones defined in > TestCase.fixture) could be prevented this way and the tests might even run > a bit quicker. This is quicker than flushing the database/rolling back all > changes. > > Sincerely, > Matteo Kloiber > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/da772f12-af91-471f-a8d5-1289ada00619%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
