Include nosetests out of the box with top level testing dir about cookiecutter-data-science HOT 4 CLOSED

Yes! #3 was a placeholder for this, but with no detail whatsoever. I'll close that as a dupe of this issue.

A couple thoughts:

• nose is no longer maintained 😦 , so we should go for nose2, py.test, or just vanilla unittest.
• Philosophically, I think this lives in src/tests. Generally, we think of src as what might one day get deployed or graduate to a package.
• Let's add a boilerplate test to get example syntax all in one place.
• Let's add make tests to the Makefile with whichever test runner we go with.

@isms @denisekgosnell Thoughts?

from cookiecutter-data-science.

While making a PR to specifically outline my thoughts, I missed this note. I can change to not use nosetests -- but this PR is the outline of what I was envisioning.

#26

from cookiecutter-data-science.

@pjbull To add to the discussion above:

Philosophically, I think this lives in src/tests
The level of testing that I am proposing is for the deployed models. To me, it looks like the top level data and models dir is for the trained models which will be deployed in the project. IMO, these are the scripts and pipelines which need to be wrapped in unit and integration tests.

I may be misinterpreting the difference between the top level data and models and then src/data and srd/models, so let me know how this aligns with your vision.

Thanks!

from cookiecutter-data-science.

Interesting--the way we've used this in the past is that serialized models (and model-specific results, such as cross-validation scores) live in the root models folder. We use the data folder for the data itself (e.g., csvs, sql dumps). So, neither of these contain code, which we try to isolate in notebooks (for exploratory work) and src for source files.

I'm currently leaning towards py.test as the default test runner since it will find and run tests that are written with unittest, nosetest, or py.test.

One other note: I think that probably should be conservative and leave out subfolders in tests. Some people may want to organize by test class, but others may want to organize by the module being tested or the fixtures the tests use. We'll leave those subfolder up to the users.

from cookiecutter-data-science.