Closed paulcollinsiii closed 9 years ago
Why switch to py.test instead of nose2?
Scratch that. I read through nose2 docs and I don't see anything compelling there. I'm game for switching to py.test, though my experience with py.test is pretty limited.
@willkg ya nose2 is still very much in development and py.test I've found to be really really solid. Downside is it has a LOT of knobs and dials you can tweak, so the learning curve is a bit higher. Upside though is you can do all the unit-test style things you did in nose, with test generation. Plus you get the shiny reuse-db options and there's a plugin to run BDD style tests all from the same test runner / collector.
Seems like the tests are failing because some of the settings aren't defined like CACHES.
Any ideas? Is this something you want me to look into?
@willkg no need. It's just me screwing up the travis file again =/
Got a bit further with the factory_boy stuff though. Hopefully I'll get the remaining non-factory boy stuff converted soon and then I'll add a test for the default creation on all the factories to make sure they work without arguments.
@willkg okay so assuming this build passes (and if it doesn't I'll fix after dinner) you now have factory_boy factories :sparkles:
this PR resolves #252 (just to setup the reference links)
I landed all the settings things in master branch.
Two things to know:
Can you update your remote and prune this branch down to just what's new since latest master tip?
If that sounds icky, I can do totally that work. Either way works for me--just let me know.
@willkg found the last couple issues hanging around in the tests. Also I explicitly set the version of steve so people with installs already will get upgraded. My tox env had 0.3 which was causing other failures for me. Not sure if you want to change that to be a min version required rather than an exact.
This looks ok except that you ditched the sampledata generation. Sampledata generation makes it easier to do development on richard.
I didn't see anything in the commit messages about why you removed that code. Was it problematic in some way?
@willkg Was that sample data generation being used outside of the test suite? If so it's probably not too bad to put in some "generate_fake_data" to actually push into the prod DB using the factory boy stuff.
I had removed it because I thought it was only used during testing. Thus, I wanted to discourage people from using (and thus having to maintain) two different ways of generating test data.
The sampledata generation had nothing to do with tests. It uses eadred to make it easy to generate sample data for your development database so you have something to work with. Otherwise you have to build it by hand and that's difficult especially if you don't know what it looks like.
I think what I'll do is land this and then re-add that. I'll try to do that today.
Awesome! Merging now!
This is based on my settings_redux branch, but it converts the tests to py.test w/ pytest-django and moves the tests into the /tests folder. Reason for the conversion to py.test is that nose 1.x is in maintenance mode (https://mail.python.org/pipermail/python-announce-list/2014-March/010240.html)
I'll continue working on this PR to convert to factory boy as well which should take care of the horrible I've committed in videos.sampledata