{"id":22313694,"url":"https://github.com/ctb/somepackage","last_synced_at":"2025-06-25T23:04:31.669Z","repository":{"id":66659640,"uuid":"535138","full_name":"ctb/SomePackage","owner":"ctb","description":"A simple example package for thinking about test packaging.","archived":false,"fork":false,"pushed_at":"2013-11-17T22:06:07.000Z","size":132,"stargazers_count":29,"open_issues_count":0,"forks_count":9,"subscribers_count":4,"default_branch":"master","last_synced_at":"2025-04-05T11:11:26.511Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"bsd-2-clause","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/ctb.png","metadata":{"files":{"readme":"README.txt","changelog":null,"contributing":null,"funding":null,"license":"LICENSE.txt","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2010-02-25T04:33:06.000Z","updated_at":"2022-04-20T07:51:44.000Z","dependencies_parsed_at":"2023-02-20T08:45:30.853Z","dependency_job_id":null,"html_url":"https://github.com/ctb/SomePackage","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/ctb/SomePackage","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ctb%2FSomePackage","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ctb%2FSomePackage/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ctb%2FSomePackage/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ctb%2FSomePackage/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/ctb","download_url":"https://codeload.github.com/ctb/SomePackage/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ctb%2FSomePackage/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":261967126,"owners_count":23237662,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-12-03T22:07:56.686Z","updated_at":"2025-06-25T23:04:31.636Z","avatar_url":"https://github.com/ctb.png","language":"Python","funding_links":[],"categories":[],"sub_categories":[],"readme":"A simple example of my proposed \"how to package tests\" standard.  What do\nyou think?  --titus\n\n--\n\nTo run the tests, you can do:\n\n  % python -m somepackage.tests.__main__\n\nunder Python 2.5 or above, and\n\n  % python setup.py test\n\nif you have setuptools or Distribute installed.  This mechanism will also\nbe supported under distutils2, or distutils under 3.3 and above.\n\nYou can also run\n\n  % nosetests\n\nwith nose.\n\nHow about py.test?  Other test runners?\n\n---\n\nRules, in brief:\n----------------\n\n - for a given package, 'python -m somepackage.tests.__main__' should run\n   its tests, if any.\n\n - no code outside of 'somepackage.tests' should depend on\n   'somepackage.tests'.  This is so that distrib packagers (debian,\n   redhat) can omit the sub-package from the non-devel install.\n\nRules, with a bit more exposition:\n----------------------------------\n\nTests should generally be run at build time, but may not be runnable\nafter installation.  Nonetheless we want to specify how to do it in\ncase people want to install them.\n\nAs long as distrib packagers can remove the \u003cpackage\u003e/tests directory\nfrom their distributed version of your package, they will be happy.\nTherefore the rest of the package should not depend on anything in\n\u003cpackage\u003e/tests.\n\n---\n\nResults of testing-in-python discussion, 2/27:\n\n - Matt Harrison: explicitly suggest placing test data (data used ONLY\n   for tests) under the tests package directory.\n\n - Michael Foord: tests/ should be a package (contain an __init__.py),\n   so that it is discoverable and Python can handle it.\n\n - Michal Kwiatkowski: explicitly suggest putting other tests in\n   tests/ top-level directory.\n\n - Michal Kwiatkowski: also look at\n\n      http://time-loop.tumblr.com/post/49578950/where-python-developers-keep-their-test-directories\n\n   to see where people put their test directories.\n\n - Michael Foord: make the mechanism framework agnostic.\n\n - Titus Brown: rely on something other than specific module\n   runtime semantics; so\n\n     python setup.py test\n\n   or something in the style of\n\n     python -m somepackage.tests\n\n   is better than 'python -m unittest somepackage' or whatnot.\n\n - All right thinking people agree that supporting suites from test\n   tools other than unittest in setup.py would be nice.\n\n - Michael Foord: the 'suite' callable mentioned in unittest\n   documentation isn't actually used or enforced, so it does not\n   clash, collide, or make redundant the 'test_suite' collable\n   convention defined in setuptools.\n\n - Michael Foord: for modules loaded with a TestLoader the load_tests\n   function is better. For executing suites directly you can *now* do:\n   python -m unittest package.module.suitename.\n\n - Michael Ford in response to Robert Collins: \"So the real\n   requirement is that the package / module specified should either be\n   a standard unittest package - or provide a load_tests function that\n   returns a unittest compatible TestSuite-like object, capable of\n   being run with a TextTestRunner.\n\n   If all test frameworks can adhere to this then I'm fine with dropping the\n   'run' module requirement.\"\n\n - Michael Foord in response to Titus Brown: \"load_tests is already a\n   convention. This particular hook allows you to interoperate with\n   unittest whilst avoiding most of the snakes. If you have *specific*\n   problems with this approach then I'd like to hear about them. :-)\"\n\n - Titus Brown: I should write up examples of using load_tests,\n   test_suite (in setuptools), test_runner (in setuptools), discover\n   (in unittest2/3rd-party package), and '-m unittest' (which may be\n   redundant with one of the above?)\n\n - Titus Brown: I also don't really understand what the arguments to\n   'setup.py test' are.\n\nLonger e-mail from Michael:\n\n\u003e Perhaps the convention could be that you provide an executable run module\n\u003e only if the distutils2 defaults aren't adequate. In this case the\n\u003e arguments you supply in setup.py tests/testrunner arguments will have to\n\u003e do the same job as your run module (duplication).\n\u003e\n\u003e We could come up with a more complex scheme for distutils2 that meets all\n\u003e these usecases:\n\u003e\n\u003e If no arguments are specified in setup.py then \"setup.py test\" does the\n\u003e following:\n\u003e \n\u003e For each package in the distribution that supplies a test sub-package\n\u003e including a run module, execute the equivalent of:\n\u003e \n\u003e python -m package.test.run\n\u003e \n\u003e For all packages that don't provide a test.run sub-package and module\n\u003e attempt test discovery.       \n\u003e \n\u003e If tests/testrunner arguments are supplied to setup.py then those will be\n\u003e used and the programmer should also provide a test.run if he wants tests to\n\u003e be able to be run without setup.py being used.\n\u003e This kind of makes the setup.py arguments redundant, or at least slightly\n\u003e harmful to use them without providing test.run as well.\n\n---\n\nConcerns: how flexible is 'python setup.py test'?  Can it be framework\nagnostic, or do frameworks have to expose a unittest-like framework\n(e.g. what nose has done)?\n\nAnother point: I like the idea of being able to specify other test\nrunners, with unittest being the default one.  Once we have that\nlevel of API compliance then we can do all sorts of nice things;\nmore once I work through some examples.\n\n@@CTB revisit test_suite / test_runner in setuptools\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fctb%2Fsomepackage","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fctb%2Fsomepackage","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fctb%2Fsomepackage/lists"}