A

https://leetcode-cn.com/problems/increasing-subsequences/submissions/

花了这么多的时间，歇会吧…

但还是忍不住想记录下，没提交被测试跑过之前，对这个题目描述的潜在的场景描述的很不足够…

R

pytest的所谓测试发现

Conventions for Python test discovery

pytest implements the following standard test discovery:

• If no arguments are specified then collection starts from testpaths (if configured) or the current directory. Alternatively, command line arguments can be used in any combination of directories, file names or node ids.
  
• Recurse into directories, unless they match norecursedirs.
  
• In those directories, search for test_*.py or *_test.py files, imported by their test package name.
  
• From those files, collect test items:
  • test prefixed test functions or methods outside of class
    
  • test prefixed test functions or methods inside Test prefixed test classes (without an __init__ method)
    

For examples of how to customize your test discovery Changing standard (Python) test discovery.

Within Python modules, pytest also discovers tests using the standard unittest.TestCase subclassing technique.

关于Python 测试发现的约定

pytest实现了以下的标准的测试发现：

• 如果没有指定参数那么会从testpaths（如果配置了的话）或者当前目录开始收集。相对的，命令行参数可以在目录、文件名或节点id任意的组合
• 递归的进入目录中，除非匹配到了norecursedirs这个配置项
• 在这些目录中，搜索 test_ 前缀或者_test 后缀的py文件，通过他们的测试包名导入（这段没太明白）
• 这些文件当中，收集这些测试项：
  • 类之外的以test为前缀的函数
  • 在以Test为前缀的测试类中的test前缀的测试方法（这些类不包含init方法）

如何定制自己的测试发现的栗子，参考这里，在Python 模块中，pytest也发现那些使用标准unittest.TestCase 子类型化技术的测试，具体说明参照

有必要补充一些概念

• testpaths和 norecursedirs这两个配置值，都可以在pytest.ini中配置
  • 有介绍这个配置的，但是还没找到这个配置文件约定放在哪儿？
  • 这个配置文件的位置，参考这里描述
• 目录、文件名、节点ids组合那个没懂，特别是node ids不知道是个啥玩意儿
• 测试包名这个，也就是pytest命令行执行时候的—pyargs参数，完全不明白怎么回事，没有这句还挺明白的，有了很糊涂
• 改变标准的测试发现的那些栗子…值得试试，以便能更理解缺省规则的
• unittest的其实不懂，没有循序渐进的坏处吧，目前已知的unittest的罗嗦的地方
  • 要继承unittest.TestCase，这里已经提到
  • 断言有点罗嗦，因为unittest是以JUnit为模仿对象的吧

T

先记一个兜底：

• pycharm里面的run configuration里面配置的执行特定.py文件里面的test，有可能不满足pytest缺省的测试发现规则，这个我没验证，是因为有一个组员提交的代码中，py文件是用的驼峰，而不是test_这种前缀命名的，所以没有收集到测试

每周的水

我可已从一个编辑窗口中copy一段text并以富文本的方式粘贴到另一个可以识别RTF的窗口中

要确保，Copy as rich text by default复选框是被选中的，配置在Settings/Preferences 的 Editor | General页，可以按Ctrl+Alt+S 呼出

照着来了一遍，结果如图：

UI明显都变了，简直每周这个变成吐槽专用吧

S

这周关于测试的东西弄得比较多，记录几个，主要都是关于：

和测试开发的兄弟讨论自制的框架和使用pytest这类通用框架之间的差别

• 这个有必要简要记述一下背景：
  • 做的是接口测试，就是一堆http的endpoint
  • 测开的兄弟是设计了一个excel表格，用来记录每一个接口要请求的测试地址、期望结果、实际结果、是否成功
• 我认为测开同学的自制框架有点造轮子了，而且会有大量的代码篇幅去适应这个表格设计的结构，而不是关注于接口本身了
• 我还提出了一个问题和一种解决方案，就是并不太适合于细致的比对预期的结果的细节项
  • 我提出的解决方案是留一个虚函数接口，让后面使用框架的同学来填充这个接口
  • 测开同学则针对我提出的这个具体的问题，在excel表格中增加了一列叫做“待检查字段”，用于声明excel预期结果那列里面那些字段是要进行值检查的
• 我其实觉得测开同学的方法针对我提出的问题的解决还是挺不错的，虽然我依然先入为主的认为其实没有比要开发这么一个框架，而是直接维护pytest case就可以了
  • 接口测试代码都是很直观的：
    • 测试夹具setup的准备
    • 首测对象的请求
    • 检查受测对象返回的值
  • 把上述流程再抽象出来我觉得有点过度设计，反倒不直观
• 测试开发的规格化的excel表格设计，不是太灵活
  • 比如适应json请求响应格式一种还是比较容易的，如果加别的，估计又得增加列
  • 量大了，也未必好维护，一个大excel，定位到特定的case并查看细节其实干扰项挺多
• 实际的开发过程中还遇到这么些问题
  • python自制程序的入口问题
    • 按说就是file到绝对路径的试别，但是pytest的话有一个发现规则基本上可以省了
  • 结果汇总问题
    • 侧开同学那里叫做report，但是我觉得其实report应该输出更多的内容
      • 而且可能需要结合其他的测试工具来做
  • 另一个其实也算汇总，就是返回错误码
    • 本身也是和CI工具集成的便捷度的问题，其实pytest本身也是这么做的
    • sys.exit()函数（这条写的有点像tip了？那就再加一个tip，如果是window，那么需要echo %errorlevel%，而不是echo $?）
  • assert 断言判断两个列表的问题，可以用set，python里面要注意列表元素要符合一定要求，就是估计得实现hash函数之类的，所以tuple当元素可以，但是list不行