Expand on the testing directory about sampleproject HOT 11 CLOSED

@pfmoore having the sampleproject try to cover all best practices is feeling overwhelming at the moment. I only feel comfortable trying to maintain this for packaging best practices. I'll wait for your response, but I'm inclined to close the non-packaging issues, and maybe remove the tests directory all together, so it's clear we're not even trying to offer guidance there.

from sampleproject.

@qwcode Given that nobody seems able/willing to give good recommendations about wider project practices (something I found out when this was a personal project from questions I asked on PyPA and distutils-sig) I have to agree.

Whether that leaves enough meat to make this project worthwhile as a reference (as opposed to simply documenting the recommendations in the PUG) I'm not sure.

I'm -1 on actually removing the tests directory, as that makes the project largely useless for the purpose I originally intended it, i.e. as a starting point.

from sampleproject.

@pfmoore for example, see PR #5 . It's advocating nose, and very heavy use of pylint. I don't think PyPA should get into that.

I do see PyPA advocating whether to include tests in the sdist or have them installed. So, for that reason, having tests in the sample makes senses, so I won't remove them

Apologies, if it feels like Pypa (or me) took your project, and changed the scope. Think of it as a contribution, vs a loss : )

If you want, we can change the name to "sample_packaging_project", so you could continue on with your broader effort back in your personal github workspace. let me know.

Even with the reduced scope, I do still think it's worthwhile to keep, and the PUG is currently linking to it multiple times.

from sampleproject.

@qwcode no, it's not a problem. I think the reality is that there isn't a "Python project best practice" at this point, so there is bound to be debate. But I do think this should remain usabe as a "copy this and start developing" template, so I'm happy that the tests directory remains - there should be a reminder that people should be writing tests, even if we can't offer any advice on how.

On that note, maybe we need a "docs" directory as well?

from sampleproject.

@pfmoore you can add docs if you want, but I won't personally partake in any PRs where people quibble about sphinx practices. my interest in the docs directory would be how it relates to packaging, e.g. how to make sure your docs are installed, if that's important for some reason.

from sampleproject.

About the PR #5, I have to precise that my idea was to propose only the two first commit as a pull request. As I lack experience with Github, I had not anticipated that the remainder would be integrated into the PR.
I fully understand that not anyone is so Pylint-maniac as I am, and that this is not the place for my personal recipes.
Though, I think it's important that the 'python setup.py install' works in a fresh virtualenv, especially for saving time of beginners, for whom small corrections of syntax and imports can be painful.
Optionally, always thinking beginners, I think it's logic to have a basic class and a basic test in a sample project (but without requiring nose). Something saying like «Welcome to python, you will write classes and tests, and this is good».

If you agree with this principles, I can make a new pull request corresponding to this requirements.

from sampleproject.

@qwcode OK, if there's Sphinx controversy, you're right, let's not get into that. Leave docs for peoplr to add themselves...

from sampleproject.

I would actually find a slightly more complex example of how tests should be structured to be useful (eg more than one test file).

I used the sampleproject as the base for my project, then read instructions in unittest and nose that all of my tests should "importable" for test discovery. I came back to sampleproject to see how that'd been accomplished with the tests in a separate directory from the other code, but it didn't demonstrate this.

I understand the desire to be framework-agnostic, but it'd be nice to have some demonstration of a scaleable way to write tests using one of the popular frameworks (whether it's unittest, nose, py.test). I don't know if all unittest/nose projects structure things differently to sampleproject so tests can be imported as, eg myproject.tests, or if they just use one of the special entry-point scripts which manipulate the PYTHONPATH, and I'd find it useful if some sample project existed which showed a "recommended" setup.

from sampleproject.

@ncraike I don't think there is any common approach, unfortunately. With py.test (which is what I prefer these days) you don't even want the tests to be importable (and I think making them so is problematic).

So there really isn't anything we can do beyond having a tests directory before we get into making framework recommendations :-( (Actually, even having a tests directory is a decision - many projects seem to include tests within the distributed package itself).

from sampleproject.

(Thanks for the quick reply.)

Ah, right. Yeah, I was trying to get a sense of what is done outside of the couple of really big, old projects I've worked on. Even knowing that there isn't an agreed upon standard is valuable.

I can certainly understand the argument for not installing your test code along with the code your project needs to actually do its job. I've also seen others advocate keeping your unit tests right next to the code they test, with the argument that everyone knows where they are, then.

Well, I guess I'll just pick something, and not so feel bad that it isn't "best practice".

from sampleproject.

I know that feeling completely :-) These days, I tend to use py.test and just base what I do on pip's setup (which is very complex, but the basics are straightforward enough) just because it's what I'm most familiar with. I suspect that's a common approach.

BTW, I'm going to close this issue, as we're not likely to do anything with it, so no point in it just sitting here.

from sampleproject.