-
Notifications
You must be signed in to change notification settings - Fork 137
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Basic tests for some website importers #717
Conversation
Note: we had some tests previously in the gourmet/test/ directory. The If you want to use that infrastructure, I haven't looked at it in a while, It might be worth standardizing where we put these things and how we name Tom On Tue, May 7, 2013 at 1:31 PM, jens persson [email protected]:
|
Thank you for your contribution, and sorry for taking so long to review! I've merged your work into the master branch, but moved the tests to the gourmet/test directory and modified them quite a bit, producing a schema_org_parser from which the ica.se importer now derives, as does the updated allrecipes.com importer. @thinkle I've tried to integrate these new/updated importer tests into gourmet/test/testImporter.py, but even with quite some effort couldn't manage to enable them to use offline copies of the sample web pages they parse which IMO is crucial (eg for testing as part of downstream packaging -- Debian can perform tests at build time, but it's mandatory that they work without an Internet connection). Unfortunately, everything's just so intertwined in the (interactive) importer/plugin/parser part of the code, so I'm sticking to MrShark's individual test files for now. In the long run (ie when using SQLAlchemy's ORM, that is issue #712), I hope to simplify the structure of plugins and importers so we can have actual unit tests that deserve the name and don't rely on a plethora of other modules. |
Hello,
I have finally had the time to sit down and hack on some unittests for the website importers, they are quite crude but they give some coverage and are something to build on.
They use locally cached versions of the webpages to not slow down testing to much with networking. My thinking is to extend them later with some "slow tests" that can be run to detect if the website have changed enough to make the plugin stop working.
I have used nose to run them, which finds some other tests that's not runnable as unittests so I will probably do some clean-up/renaming to make then usable or skipped.