mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-01 21:50:13 +08:00
Merge remote-tracking branch 'LCTT/master'
This commit is contained in:
Xingyu.Wang
commit
950c84c659
@ -1,28 +1,26 @@
|
||||
Perform robust unit tests with PyHamcrest
|
||||
使用 PyHamcrest 执行健壮的单元测试
|
||||
======
|
||||
> 使用此框架编写断言，提高开发测试的准确性。
|
||||
|
||||
|
||||
|
||||
在[测试金字塔][1]的底部是单元测试。单元测试每次只测试一个代码单元，通常是一个函数或方法。
|
||||
|
||||
通常，设计单个单元测试是为了测试通过函数或特定分支选择的特定流，这使得失败的单元测试和导致失败的 bug 之间的映射变得容易。
|
||||
通常，设计单个单元测试是为了测试通过一个函数或特定分支的特定执行流程，这使得将失败的单元测试和导致失败的 bug 对应起来变得容易。
|
||||
|
||||
理想情况下，单元测试使用很少或不使用外部资源，从而隔离它们并使它们更快。
|
||||
理想情况下，单元测试很少使用或不使用外部资源，从而隔离它们并使它们更快。
|
||||
|
||||
_好_ 测试通过尽早发现 bug 并加快测试速度来提高开发人员的工作效率。_坏_ 测试降低了开发人员的工作效率。
|
||||
单元测试套件通过在开发过程的早期发现问题来帮助维护高质量的产品。有效的单元测试可以在代码离开开发人员机器之前捕获 bug，或者至少可以在特定分支上的持续集成环境中捕获 bug。这标志着好的和坏的单元测试之间的区别：*好的*测试通过尽早捕获 bug 并使测试更快来提高开发人员的生产力。*坏的*测试降低了开发人员的工作效率。
|
||||
|
||||
单元测试套件通过在开发过程的早期发现问题来帮助维护高质量的产品。有效的单元测试在代码离开开发人员机器之前捕获 bug，或者至少在特定分支上的持续集成环境中捕获 bug。这标志着好的和坏的单元测试之间的区别：好的测试通过尽早捕获 bug 并使测试更快来提高开发人员的生产力。坏的测试降低了开发人员的工作效率。
|
||||
|
||||
当测试 _附带的特性_ 时，生产率通常会降低。当代码更改时测试失败，即时它仍然是正确的。发生这种情况是因为输出不同，但在某种程度上它不是函数契约的一部分。
|
||||
当测试*附带的特性*时，生产率通常会降低。当代码更改时测试会失败，即使它仍然是正确的。发生这种情况是因为输出的不同，但在某种程度上是因为它不是<ruby>函数契约<rt>function's contract</rt></ruby>的一部分。
|
||||
|
||||
因此，一个好的单元测试可以帮助执行函数所提交的契约。
|
||||
|
||||
如果单元测试中断，那意味着契约被违反了，应该明确修改（通过更改文档和测试），或者被修复（通过修复代码并保持测试不变）。
|
||||
如果单元测试中断，那意味着该契约被违反了，应该（通过更改文档和测试）明确修改，或者（通过修复代码并保持测试不变）来修复。
|
||||
|
||||
虽然将测试限制为只执行公共契约是一项需要学习的复杂技能，但有一些工具可以提供帮助。
|
||||
|
||||
其中一个工具是 [Hamcrest][2]，一个用于编写断言的框架。最初是为基于 Java 的单元测试而发明的，它现在支持多种语言，包括 [Python][3]。
|
||||
其中一个工具是 [Hamcrest][2]，这是一个用于编写断言的框架。最初是为基于 Java 的单元测试而发明的，但它现在支持多种语言，包括 [Python][3]。
|
||||
|
||||
Hamcrest 旨在使测试断言更容易编写和更精确。
|
||||
|
||||
@ -36,7 +34,8 @@ def test_add():
|
||||
assert_that(add(2, 2), equal_to(4))
|
||||
```
|
||||
|
||||
这是一个用于简单功能的断言。如果我们想要断言更复杂的怎么办？
|
||||
这是一个用于简单函数的断言。如果我们想要断言更复杂的函数怎么办？
|
||||
|
||||
```
|
||||
def test_set_removal():
|
||||
my_set = {1, 2, 3, 4}
|
||||
@ -45,13 +44,14 @@ def test_set_removal():
|
||||
assert_that(my_set, is_not(has_item(3)))
|
||||
```
|
||||
|
||||
注意，我们可以简单地断言结果的顺序为 `1`, `2` 和 `4`，因为集合不保证顺序。
|
||||
注意，我们可以简单地断言其结果是任何顺序的 `1`、`2` 和 `4`，因为集合不保证顺序。
|
||||
|
||||
我们也可以很容易用 `is_not` 来否定断言。这有助于我们编写 _精确的断言_，使我们能够把自己限制在执行职能的公共契约方面。
|
||||
我们也可以很容易用 `is_not` 来否定断言。这有助于我们编写*精确的断言*，使我们能够把自己限制在执行函数的公共契约方面。
|
||||
|
||||
然而，有时候，内置功能都不是我们 _真正_ 需要的。在这些情况下，Hamcrest 允许我们编写自己的匹配器。
|
||||
然而，有时候，内置的功能都不是我们*真正*需要的。在这些情况下，Hamcrest 允许我们编写自己的<ruby>匹配器<rt>matchers</rt></ruby>。
|
||||
|
||||
想象一下以下功能：
|
||||
|
||||
```
|
||||
def scale_one(a, b):
|
||||
scale = random.randint(0, 5)
|
||||
@ -59,9 +59,10 @@ def scale_one(a, b):
|
||||
return scale * pick
|
||||
```
|
||||
|
||||
我们可以自信地断言结果均匀地划分为至少一个输入。（to 校正：？？？什么意思）
|
||||
我们可以自信地断言其结果均匀地分配到至少一个输入。
|
||||
|
||||
匹配器继承自 `hamcrest.core.base_matcher.BaseMatcher`，重写两个方法：
|
||||
|
||||
```
|
||||
class DivisibleBy(hamcrest.core.base_matcher.BaseMatcher):
|
||||
def __init__(self, factor):
|
||||
@ -76,12 +77,14 @@ class DivisibleBy(hamcrest.core.base_matcher.BaseMatcher):
|
||||
```
|
||||
|
||||
编写高质量的 `describe_to` 方法很重要，因为这是测试失败时显示的消息的一部分。
|
||||
|
||||
```
|
||||
def divisible_by(num):
|
||||
return DivisibleBy(num)
|
||||
```
|
||||
|
||||
按照惯例，我们将匹配器包装在一个函数中。有时这给了我们进一步处理输入的机会，但在这种情况下，我们不需要进一步处理。
|
||||
|
||||
```
|
||||
def test_scale():
|
||||
result = scale_one(3, 7)
|
||||
@ -92,7 +95,8 @@ def test_scale():
|
||||
|
||||
请注意，我们将 `divisible_by` 匹配器与内置的 `any_of` 匹配器结合起来，以确保我们只测试函数提交的内容。
|
||||
|
||||
在编辑这篇文章时，我听到一个传言，“Hamcrest” 这个名字被认为是 “matches” 的字谜。人力资源管理...
|
||||
在编辑这篇文章时，我听到一个传言，取 “Hamcrest” 这个名字是因为它是 “matches” 字母组成的字谜。嗯...
|
||||
|
||||
```
|
||||
>>> assert_that("matches", contains_inanyorder(*"hamcrest")
|
||||
Traceback (most recent call last):
|
||||
@ -106,13 +110,14 @@ Expected: a sequence over ['h', 'a', 'm', 'c', 'r', 'e', 's', 't'] in any order
|
||||
but: no item matches: 'r' in ['m', 'a', 't', 'c', 'h', 'e', 's']
|
||||
```
|
||||
|
||||
经过进一步的研究，我找到了谣言的来源：它是 “matchers” 的字谜。
|
||||
经过进一步的研究，我找到了传言的来源：它是 “matchers” 字母组成的字谜。
|
||||
|
||||
```
|
||||
>>> assert_that("matchers", contains_inanyorder(*"hamcrest"))
|
||||
>>>
|
||||
```
|
||||
|
||||
如果你还没有为你的 Python 代码编写单元测试，那么现在是开始的好时机。如果你正在为你的 Python 代码编写单元测试，那么使用 Hamcrest 将允许你使你的断言更加 _精确_，既不会比你想要测试的多也不会少。这将在修改代码时减少误报，并减少修改工作代码的测试所花费的时间。
|
||||
如果你还没有为你的 Python 代码编写单元测试，那么现在是开始的好时机。如果你正在为你的 Python 代码编写单元测试，那么使用 Hamcrest 将允许你使你的断言更加*精确*，既不会比你想要测试的多也不会少。这将在修改代码时减少误报，并减少修改工作代码的测试所花费的时间。
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
@ -121,8 +126,8 @@ via: https://opensource.com/article/18/8/robust-unit-tests-hamcrest
|
||||
|
||||
作者：[Moshe Zadka][a]
|
||||
选题：[lujun9972](https://github.com/lujun9972)
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
译者：[MjSeven](https://github.com/MjSeven)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -1,114 +0,0 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (How to open source your Python library)
|
||||
[#]: via: (https://opensource.com/article/18/12/tips-open-sourcing-python-libraries)
|
||||
[#]: author: (Moshe Zadka https://opensource.com/users/moshez)
|
||||
|
||||
How to open source your Python library
|
||||
======
|
||||
This 12-step checklist will ensure a successful launch.
|
||||
|
||||
|
||||
You wrote a Python library. I'm sure it's amazing! Wouldn't it be neat if it was easy for people to use it? Here is a checklist of things to think about and concrete steps to take when open sourcing your Python library.
|
||||
|
||||
### 1\. Source
|
||||
|
||||
Put the code up on [GitHub][1], where most open source projects happen and where it is easiest for people to submit pull requests.
|
||||
|
||||
### 2\. License
|
||||
|
||||
Choose an open source license. A good, permissive default is the [MIT License][2]. If you have specific requirements, Creative Common's [Choose a License][3] can guide you through the alternatives. Most importantly, there are three rules to keep in mind when choosing a license:
|
||||
|
||||
* Don't create your own license.
|
||||
* Don't create your own license.
|
||||
* Don't create your own license.
|
||||
|
||||
|
||||
|
||||
### 3\. README
|
||||
|
||||
Put a file called README.rst, formatted with ReStructured Text, at the top of your tree.
|
||||
|
||||
GitHub will render ReStructured Text just as well as Markdown, and ReST plays better with Python's documentation ecosystem.
|
||||
|
||||
### 4\. Tests
|
||||
|
||||
Write tests. This is not useful just for you: it is useful for people who want to make patches that avoid breaking related functionality.
|
||||
|
||||
Tests help collaborators collaborate.
|
||||
|
||||
Usually, it is best if they are runnable with [**pytest**][4]. There are other test runners—but very little reason to use them.
|
||||
|
||||
### 5\. Style
|
||||
|
||||
Enforce style with a linter: PyLint, Flake8, or Black with **\--check**. Unless you use Black, make sure to specify configuration options in a file checked into source control.
|
||||
|
||||
### 6\. API documentation
|
||||
|
||||
Use docstrings to document modules, functions, classes, and methods.
|
||||
|
||||
There are a few styles you can use. I prefer the [Google-style docstrings][5], but [ReST docstrings][6] are an option.
|
||||
|
||||
Both Google-style and ReST docstrings can be processed by Sphinx to integrate API documentation with prose documentation.
|
||||
|
||||
### 7\. Prose documentation
|
||||
|
||||
Use [Sphinx][7]. (Read [our article on it][8].) A tutorial is useful, but it is also important to specify what this thing is, what it is good for, what it is bad for, and any special considerations.
|
||||
|
||||
### 8\. Building
|
||||
|
||||
Use **tox** or **nox** to automatically run your tests and linter and build the documentation. These tools support a "dependency matrix." These matrices tend to explode fast, but try to test against a reasonable sample, such as Python versions, versions of dependencies, and possibly optional dependencies you install.
|
||||
|
||||
### 9\. Packaging
|
||||
|
||||
Use [setuptools][9]. Write a **setup.py** and a **setup.cfg**. If you support both Python 2 and 3, specify universal wheels in the **setup.cfg**.
|
||||
|
||||
One thing **tox** or **nox** should do is build a wheel and run tests against the installed wheel.
|
||||
|
||||
Avoid C extensions. If you absolutely need them for performance or binding reasons, put them in a separate package. Properly packaging C extensions deserves its own post. There are a lot of gotchas!
|
||||
|
||||
### 10\. Continuous integration
|
||||
|
||||
### 11\. Versions
|
||||
|
||||
Use a public continuous integration runner. [TravisCI][10] and [CircleCI][11] offer free tiers for open source projects. Configure GitHub or other repo to require passing checks before merging pull requests, and you'll never have to worry about telling people to fix their tests or their style in code reviews.
|
||||
|
||||
Use either [SemVer][12] or [CalVer][13]. There are many tools to help manage versions: [incremental][14], [bumpversion][15], and [setuptools_scm][16] are all packages on PyPI that help manage versions for you.
|
||||
|
||||
### 12\. Release
|
||||
|
||||
Release by running **tox** or **nox** and using **twine** to upload the artifacts to PyPI. You can do a "test upload" by running [DevPI][17].
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/12/tips-open-sourcing-python-libraries
|
||||
|
||||
作者：[Moshe Zadka][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/moshez
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://github.com/
|
||||
[2]: https://en.wikipedia.org/wiki/MIT_License
|
||||
[3]: https://choosealicense.com/
|
||||
[4]: https://docs.pytest.org/en/latest/
|
||||
[5]: https://github.com/google/styleguide/blob/gh-pages/pyguide.md
|
||||
[6]: https://www.python.org/dev/peps/pep-0287/
|
||||
[7]: http://www.sphinx-doc.org/en/master/
|
||||
[8]: https://opensource.com/article/18/11/building-custom-workflows-sphinx
|
||||
[9]: https://pypi.org/project/setuptools/
|
||||
[10]: https://travis-ci.org/
|
||||
[11]: https://circleci.com/
|
||||
[12]: https://semver.org/
|
||||
[13]: https://calver.org/
|
||||
[14]: https://pypi.org/project/incremental/
|
||||
[15]: https://pypi.org/project/bumpversion/
|
||||
[16]: https://pypi.org/project/setuptools_scm/
|
||||
[17]: https://opensource.com/article/18/7/setting-devpi
|
||||
@ -1,5 +1,5 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: translator: (xiqingongzi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
@ -88,7 +88,7 @@ via: https://opensource.com/article/19/1/pygame-zero
|
||||
|
||||
作者：[Moshe Zadka][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
译者：[xiqingongzi](https://github.com/xiqingongzi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
|
||||
@ -0,0 +1,115 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (How to open source your Python library)
|
||||
[#]: via: (https://opensource.com/article/18/12/tips-open-sourcing-python-libraries)
|
||||
[#]: author: (Moshe Zadka https://opensource.com/users/moshez)
|
||||
|
||||
如何开源你的 Python 库
|
||||
======
|
||||
这 12 个步骤能确保成功发布。
|
||||
|
||||
|
||||
你写了一个 Python 库。我觉着这太棒了！如果让人们能够轻松使用它不是很优雅么？这有一个需要考虑的清单，以及在开源 Python 库时要采取的具体步骤。
|
||||
|
||||
### 1\. 源码
|
||||
|
||||
将代码放在 [GitHub][1] 上，这里有很多开源项目，并且人们很容易提交拉取请求。
|
||||
|
||||
### 2\. 许可证
|
||||
|
||||
选择一个开源许可证。默认的一个不错的，宽容的是 [MIT 许可][2]。如果你有特定要求，Creative Common 的[选择许可][3]可以指导你完成其他选择。最重要的是，在选择许可时要记住三条规则：
|
||||
|
||||
|
||||
* 不要创建自己的许可证。
|
||||
* 不要创建自己的许可证。
|
||||
* 不要创建自己的许可证。
|
||||
|
||||
|
||||
|
||||
### 3\. README
|
||||
|
||||
将一个名为 README.rst 的文件（使用 ReStructured Text 格式化）放在项目树的顶层。
|
||||
|
||||
GitHub 将像 Markdown 一样渲染 ReStructured Text，而 ReST 在 Python 的文档生态系统中的表现更好。
|
||||
|
||||
### 4\. 测试
|
||||
|
||||
写测试。这对你来说没有用处。但对于想要编写避免破坏相关功能的补丁的人来说，它非常有用。
|
||||
|
||||
测试可帮助协作者进行协作。
|
||||
|
||||
通常情况下，如果可以用 [**pytest**][4] 运行就最好了。还有其他测试工具 - 但很少有理由去使用它们。
|
||||
|
||||
### 5\. 样式
|
||||
|
||||
使用 linter 制定样式：PyLint、Flake8 或者带上 **\--check** 的 Black 。除非你使用Black，否则请确保在下载源代码文件中指定配置选项。
|
||||
|
||||
### 6\. API 文档
|
||||
|
||||
使用 docstrings 来记录模块、函数、类和方法。
|
||||
|
||||
你可以使用几种样式。我更喜欢 [Google 风格的 docstrings][5]，但 [ReST docstrings][6] 也是一种选择。
|
||||
|
||||
Sphinx 可以同时处理 Google 风格和 ReST 的 docstrings，以将零散的文档集成为 API 文档。
|
||||
|
||||
### 7\. 零散文档
|
||||
|
||||
使用 [Sphinx][7]。（阅读[我们这篇文章][8]。）教程很有用，但同样重要的是要指明这是什么、它有什么好处、它有什么坏处、以及任何特殊的考虑因素。
|
||||
|
||||
### 8\. 构建
|
||||
|
||||
使用 **tox** 或 **nox** 自动运行测试、linter 并构建文档。这些工具支持“依赖矩阵”。这些矩阵往往会快速增长，但你可以尝试针对合理的样本进行测试，例如 Python 版本、依赖项版本以及可能安装的可选依赖项。
|
||||
|
||||
### 9\. 打包
|
||||
|
||||
使用 [setuptools][9] 工具。写一个 **setup.py** 和一个 **setup.cfg**。如果同时支持 Python 2 和 3，请在 **setup.cfg** 中指定 universal wheel。
|
||||
|
||||
**tox** 或 **nox** 应该做的一件事是构建 wheel 并对已安装的 wheel 进行测试。
|
||||
|
||||
避免使用 C 扩展。如果出于性能或绑定的原因一定需要它们，请将它们放在单独的包中。正确打包 C 扩展可以写一篇新的文章。这里有很多问题！
|
||||
|
||||
### 10\. 持续集成
|
||||
|
||||
使用公共持续工具。[TravisCI][10] and [CircleCI][11] 为开源项目提供免费套餐。将 GitHub 或其他仓库配置为在合并拉请求之前需要先通过检查, 那么你就不必担心在代码评审中告知用户修复测试或样式。
|
||||
|
||||
### 11\. 版本
|
||||
|
||||
使用 [SemVer][12] 或 [CalVer][13]。有许多工具可以帮助你管理版本：[incremental][14]、[bumpversion][15] 和 [setuptools_scm][16] 等都是 PyPI 上的包，都可以帮助你管理版本。
|
||||
|
||||
### 12\. 发布
|
||||
|
||||
通过运行 **tox** 或 **nox** 并使用 **twine** 将文件上传到 PyPI 上发布。你可以通过在 [DevPI][17] 中“测试上传”。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/12/tips-open-sourcing-python-libraries
|
||||
|
||||
作者：[Moshe Zadka][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/moshez
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://github.com/
|
||||
[2]: https://en.wikipedia.org/wiki/MIT_License
|
||||
[3]: https://choosealicense.com/
|
||||
[4]: https://docs.pytest.org/en/latest/
|
||||
[5]: https://github.com/google/styleguide/blob/gh-pages/pyguide.md
|
||||
[6]: https://www.python.org/dev/peps/pep-0287/
|
||||
[7]: http://www.sphinx-doc.org/en/master/
|
||||
[8]: https://opensource.com/article/18/11/building-custom-workflows-sphinx
|
||||
[9]: https://pypi.org/project/setuptools/
|
||||
[10]: https://travis-ci.org/
|
||||
[11]: https://circleci.com/
|
||||
[12]: https://semver.org/
|
||||
[13]: https://calver.org/
|
||||
[14]: https://pypi.org/project/incremental/
|
||||
[15]: https://pypi.org/project/bumpversion/
|
||||
[16]: https://pypi.org/project/setuptools_scm/
|
||||
[17]: https://opensource.com/article/18/7/setting-devpi
|
||||
Loading…
Reference in New Issue
Block a user