Hi, Pyramid developers!

Here are some thoughts about what I consider a small problem for new users:
while usage of py.test is now promoted in documentation
(http://docs.pylonsproject.org/projects/pyramid/en/1.7-branch/whatsnew-1.7.html#documentation-enhancements)
scaffolds are not ready for naive usage of py.test by new comers to Pyramid,
i.e. running ``py.test [--cov]`` at new project's root collects no tests.

As I don't know if this could be considered a bug, I'd prefer opening 
discussion here, before opening a bug in the tracker or submitting a pull 
request.

What I, as new Pyramid user, attempt just after creating project via 
``pcreate -s [scaffold] [myproject]``,
and seeing the "Welcome to Pyramid.  Sorry for the convenience." message, 
is that
project is ready to be tested out of the box by py.test or tox at project's 
root.
Currently, this seems to not be the case: py.test collects no item (outputs 
"collected 0 items").

To change that, I tried to modify `alchemy` scaffold so that:
- py.test runs out-of-the-box,
- little effort is required for tox to also work.

To do that, I:
- add a `tox.ini` configuration file for py.test;
- add a `.coveragerc` configuration file for pytest-cov plugin;
- move all tests material in its own directory (``{{pacakge}}/tests/``);
- split test file in `tests/base.py` and `tests/test_myview.py`.
Full change could be found here:
https://github.com/vincent-ferotin/pyramid/commit/7240f2214509bfb3b9b1aa0705f2021808d4dd5e

Discuss-able choices I'm aware of are:
* usage of tox.ini in place of setup.cfg:
  as setup.cfg generation was removed from 1.7, and usage of tox could be 
possible,
  I've preferred putting py.test configuration in tox.ini.
  This allows small change (i.e. adding ``[tox] envlist=py35``) for also 
having tox running on the new project;
* moving tests on their own sub-directory:
  This avoids py.test scanning all project's files in order to collect 
tests, which could be perceived as slow,
  by explicitly telling it where tests stand.
  Also, this allow splitting tests into material for testing 
(`tests/base.py`) to tests them selves (`tests/test_*.py`),
  in same manner than models is splitted between `models/meta.py` and 
`models/mymodel.py`.

So, what do you guys think about that?

-- Vincent

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

Reply via email to