在我看来，正确的答案是否定的，但您会发现很多发行版都安装了测试。不应安装测试，但应将它们包含在源代码发行版中。在我看来，在理想的世界中，测试已安装的软件包应该是由软件包管理器（pip）和site-packages目录不应被测试源污染。
我最近研究了这个主题，并从各种来源收集了信息，发现了几种不同的方法来构建包含库源和测试的发行版的目录/包层次结构。这些结构中的大多数似乎已经过时，它们的发明是为了尝试解决当时旧的分发系统的不完整功能集。不幸的是，许多在线资源（较旧的博客文章/文档）仍在宣传过时的方法，因此通过在线搜索很容易找到过时的分发方法/教程。
假设您有一个名为“my_lib”的库，并且您想要构建发行版的源代码。我将展示两种流行且看似过时的方式来构建您的发行版，以及我发现最通用的第三种方式。第三种方法也可能已经过时，但这是我在发布此答案时所知道的最好的方法。 ;-)
方法#1
（有意或无意）安装测试的发行版通常使用此方法。
等级制度
+- my_lib
| +- __init__.py
| +- source1.py
| +- source2.py
| +- tests
| +- __init__.py
| +- test_1.py
| +- test_2.py
+- setup.py
方法#2
未安装测试，但应通过以下方式将它们包含在源代码发行版中：MANIFEST.in file.
等级制度
+- my_lib
| +- __init__.py
| +- source1.py
| +- source2.py
+- tests
| +- __init__.py
| +- test_1.py
| +- test_2.py
+- setup.py
方法#3（我更喜欢这个。）
这与方法 #2 非常相似，但有一点不同（src dir).
等级制度
+- src
| +- my_lib
| +- __init__.py
| +- source1.py
| +- source2.py
+- tests
| +- __init__.py
| +- test_1.py
| +- test_2.py
+- setup.py
setup.py 中的 setup() 调用
from setuptools import setup, find_packages
setup(
...
packages=find_packages('src'),
package_dir={'': 'src'},
...
)
清单文件
recursive-include tests *.py
不会安装测试，但它们将通过我们的包含在源代码分发中MANIFEST.in.
对于方法#3，你有一个src目录通常只包含一个包，即 lib 的根目录。把my_lib封装成一个src目录（目录而不是包，所以你不需要src/__init__.py）具有以下优点：
