pytest自学第二期

好，现在开始学习pytest第二章

2 pytest初级用法

2.1 通过python解释器调用 pytest

在控制台输入命令： python -m pytest 文档说这种方式相当于直接调用 pytest，唯一的不同是这样调用会把当前目录添加到sys.path （这句是重点，重点是啥，我不知道, 我不知道这有什么用c 以后就这样，如果有自己学过但是不知道的东西，就挂在那里晒着鞭尸，一直不会就一直鞭尸，直到自己参透了其中的道理再回到这里补全）

2.2 退出码

退出码方便我们看报告

pytest有以下6种退出码：

Exit code 0: 找到所有测试用例并测试通过

Exit code 1: 找到测试用例并运行但是部分测试用例运行失败

Exit code 2: 用户中断了测试

Exit code 3:执行过程中发生了内部错误

Exit code 4: pytest命令行使用错误

Exit code 5: 没有找到任何测试用例

如何查看退出码？

这个要在第三期我们才可以知道，可以在python代码中运行pytest

pytest.main() # main()括号内可以添加参数  ['参数1'，'参数2']

添加代码后，运行python文件就相当于在控制台输入pytest，重要的是，运行此代码会返回pytest的退出码

返回了退出码ExitCode.OK

这个退出码是pytest的一个枚举类中的一个值，我们怎么知道这个.OK代表着什么意思呢？

那我们找到这个枚举类看一下里面的内容就知道了

我们首先知道是 main()这个方法运行后返回的退出码，那么 main()方法一定是有这个返回值的，所以我们 Ctrl+鼠标左键，点击 main()方法

这样我们就进入了main()方法内部，然后再用同样方法进入他的返回值看一看

这样我们就找到了这个枚举类，可以看到这些常量对应的值012就是我们上面说的那些值

我们也可以在运行时直接以int方式输出退出码，这样就可以直接查看退出码的值了

补充一下，int输入有点野路子有点LOW，本身枚举类就提供.value的方法了，可以直接 print(exit_code.value)输出具体值 U•ェ•*U

2.3重试次数

pytest ‐‐maxfail=2 # 第2次测试失败后停止测试

2.4 指定/选择测试用例

现在要学习使用多种方法选择我们的测试用例，因为后续继承 jinkens后肯定是需要用户可以自动选择用例，然后调用pytest的命令运行指定的用例，所以说，需要我们能灵活运用命令运行我们想要运行的用例

2.4.1：文件篇，如何选择我们想要运行的文件

pytest test_mod.py # 使用该命令，即可随意指定文件，运行我们想要的文件

如果我想指定多个文件怎么办？

pytest test_mod.py test_mod2.py # 注意用空格分隔

如果我不想一个一个写文件名，我想运行某一个目录中的全部文件

pytest testing/

我又不想运行目录中全部的文件了，我只想运行目录中部分文件

那我们可以使用 -k关键字进行测试

还是同样的例子，如果我想运行前三个文件呢，这时 "_s" 就不够用了吧

没关系，我们可以使用 or 关键字

同理我们还可以使用 and 关键字和 not 关键字

不过即使是这样，可能有人依然不满足，你这样的话我如果使用jinkens集成，可能必要时候需要我前台选择用例，后台自动生成一个运行命令以运行相应的用例，我不能生成出来一个这样的类似正则的命令啊，这个 -k 命令可能只便捷与手动运行命令的人（而且还需要他用脑袋去想匹配规则，甚至要在事先规范化文件名才有明显效果），而对于有生成命令需求的人用 -k 目前觉得可能不太现实

目前是只有这些方法，后期再看看还能不能整整花活

2.4.2：用例篇，我如何控制我文件中想要运行的用例

我已经知道了用 pytest xx.py 这类的命令控制运行我想要运行的文件了，但是现在如果我想要运行的文件内有多个用例，但是我只想运行其中的一部分用例怎么办？当然我可以将我不想运行的用例代码注释掉，但是我觉得可能有更好的办法让我实现这种操作

举一反三，我是否能用 -k 参数筛选我想要运行的用例？

我想整活，我发现我使用 -k 关键字匹配到了我想要的大部分用例，但是有一个用例不适用于我写的规则所以不能匹配到，但是我依然想让它一起运行，所以我是不是可以在 -k 参数后，再手动添加一个我想要运行的用例？

那这样看来，可能pytest 使用了 -k搜索的集合作为最后的结果集，不能手动在继续添加其他的内容（在运行-k前先添加也不行），虽然命令没有报错，暂时时间关系我不想再继续深挖，后续集成时再继续深挖探索

那我不爽了，我就是个眼大肚子小的人，虽然工作拧螺丝，看文档我偏要造原子弹，就算以后项目可能用不到这样复杂的命令，但是你今天告诉我不支持，我就是觉得少了块东西，有一种残缺的不安全感

好消息是，pytest还有一种方法可能满足这种需求：装饰器

pytest ‐m slow  # 这种方式会运行所有通过装饰器 @pytest.mark.slow进行装饰的测试用例。

# python 代码如下
import pytest


class Test_slow(object):

    def test_1(self):
        a = 'xx'
        assert "x" in a

    @pytest.mark.slow
    def test_2(self):
        a = 'xx'
        assert "s" in a

注意，因为你使用了pytest的mark标记功能，如果你的项目目录没有 pytest.ini文件，请先自己手动建立一个该文件并填入如下代码

[pytest]
markers = slow: 冒号后为注释，可选非必填

此时运行命令，应该只运行有 slow修饰的 test_2 用例了， test_1因为没有修饰所以不会运行

如图所见，你这个装饰器是给方法加的，能不能给类加一个呢，这样我就可以涵盖整个类的用例了

答案是可以的，看我操作一下

有点意思，不过我依然有问题，你这里只是提到了用 slow修饰，这种东西到底有几个啊，我有个项目的用例可以分成若干个种类，你这个就一个不够用怎么办？能搞自定义的吗？

答案是能搞，还记得前面的那个 pytest.ini文件吗？

直接在后面添加就可以了

除了用 pytest.int文件配置外，你甚至可以修改pytest的源码实现这个需求

官方在文档中也提到了这个方式，但是我觉得可以但是没有必要，理由如下：

1.改源码并不比配置文件方便,且配置文件本身不麻烦

2.修改源码会破坏pytest的内容，完全没有必要担负这个风险，后续如果pytest更新能否会覆盖你所添加的自定义内容暂且不提，pytest如果更新肯定也是优先适配配置文件类型的，这种修改源码的自定义能容能否受到影响就是不确定的风险了

3.git提交费劲，你如果修该了源码那你就必须git提交你的修改以便让其他人适用，而别人想要自定义考虑到统一性也要在pytest源码中添加他的自定义且git提交给你，首先大家同时修改一个主要框架的源码就是一件很奇葩的设定，且大家的代码风格可能还不一样，而且万一发生了上一条的风险那处理起来就是多环境的问题简直噩梦

4.修改起来不方便，pytest.ini就在项目目录，没必要每次添加都去找pytest的源代码去修改，且找到源代码还要找到相应的位置去添加，个人觉得实在没有必要，至少这个需求没有必要这样做，除非你不想让别人知道你自定义的地方在哪里故意藏在这里，或者就是想让别人看的一脸懵逼

5.这种做法相当于用笔纸就能记录的一个手机号，你却偏要把它纹身到身体上

首先进入这个文件