@neilp curl 是最好的 HTTP 命令行工具，站在巨人的肩膀上自然比重造轮子要好。以及 curl 也有 windows 版呀，你可以装上 curl windows 版，然后把代码里对 curl 的调用换成 curl.exe 试试

@humiaozuzu HyperTerm + https://github.com/d3viant0ne/hyperterm-base16-tomorrow-dark

@Aether ts github 在全局 timeline 搜索所有包含 github 的推文。给的例子长只是为了展示搜索参数的功能，其实最常用的场景就是搜索某个人说过的话， ts 'from:someone something' 就可以了

没下单……

douban 的数据做 tinder 的事情

@LXJ 嗯，所以对 fixture 我主要的点在于，其实它很多时候就是一种测试了，但是却没有被当成一个测试来对待，反而把报错传递给了依赖它的测试，这在显示上很不舒服。

单元变大这点我非常赞同，但太大的单元不好维护，这就又走回了测试拆分的路上。 deptest 也的确像是分组的解决方案，当时其实想写 nose 的 plugin 的，看了下 nose 的代码发现代码挺复杂的，一言不合就自己从头来写了，其实功能差了 nose 很多，只支持了我最常用的一些选项。写完才发现，一个测试框架要考虑的东西真的很多，不是随随便便就能重新造出轮子的😂

@LXJ 另外我还是觉得 fixture 「可以在里面写一些 assert 语句确保正确，只是它不叫 testcase 而已」这样有问题。 fixture 就是 fixture ，如果它是测试的一种， pytest 就不会专门为其定义一个概念和称谓了。 fixture 也必须是执行测试的先决条件，如果 fixture 存在失败的可能，那么就要为这段代码写测试来进行检验。

还有， fixture 如果失败，在 pytest 中会使所有依赖 fixture 的测试函数变成 ERROR at setup ，显示一堆重复的报错信息，这也是不合理的设计，因为 fixture 都已经失败，这些测试函数本就不需要执行了，而不是强行执行进入 ERROR 的状态。

@LXJ 嗯，没错，其实这些观点我也很认同，如果代入到单元测试的思想里的话 :)

但是 deptest 本身就是想打破单元测试思想才开发的工具。因为「对测试用例的执行顺序有要求」这样的事情在很多场景下是存在的，所以我想实践一下专门去组织顺序和依赖的做法，可以看做是对单元测试之外的方法论的尝试，或许最终还是会回归的单元测试上，但至少也对这种想法做了验证。

关于 testcase failed 而影响 dependent 的执行，在我的想法里，互相有依赖的测试其实可以看做一个测试组，这个测试组是单元化的，依赖链上任何一个测试失败就代表这个组的失败，这时就可以直接去 fix 这个 bug （看做整个组的 bug ）。而且因为依赖失败而没有执行的测试，其状态为 UNMET ，区别于 OK 和 FAILED ，在浏览结果的时候也是很清晰的。说白了 deptest 本质还是一种测试理念，不能套到单元测试中来理解。

@jason0916 测试是一个很大的门类，其中的方法论和专业知识也是非常体系化的，要做得很精通不比开发容易。我不是专业的测试工程师，就说说作为开发的想法。

我觉得你提到的场景里其实有两个测试需求，一个是功能测试，一个是验收测试（名词不知道用对了没有，意会一下）。添加菜品、获取菜品、菜品下单这三个接口是否正常工作，返回数据是否满足一致性要求，这个是功能测试；今天后台添加了几个菜品，用户是否能获取到，这个是验收测试。前者是对系统功能的测试，不需要固定的预设数据，在测试的时候只要添加的菜品和获取到的是一致的就可以了，所以数据甚至都可以随机生成；而后者是对用户产品层面做出的直接反映，这个就要求获取到的数据必须是明确需求的那几个了。

两个测试的目的不同，因此方式方法也会不同。 pytest ， deptest 这些都是面向程序，做功能测试的框架，用来解决验收测试的需求应该不大合适，你应该去寻找专门做验收测试的工具来完成这个事情。

另外，如果是想要自动生成测试代码，或者用配置文件的方式写测试，之前看到一个项目应该能满足这个需求: https://github.com/svanoort/pyresttest ，我自己也写过一个工具来做类似的事情 https://github.com/reorx/apibox/blob/master/apibox/testing.py 但是后来考虑到这样做会使功能受限于框架的语法和支持的字段，没有直接写测试函数灵活，这个项目就没有深入做下去了。

@jason0916 例子来了：

设置 cookie ，传递 session 的测试: https://github.com/reorx/deptest/blob/master/examples/cookie_test.py

你描述的实际场景: https://gist.github.com/reorx/dc6998569c6ec85d300804852ad796a7

@jason0916 稍等呀，一会有电脑了给你写这个场景的例子

先简单解释下取返回值的问题， with_return 为 True ，则 depend_on 的函数的返回值会再调用时传给被装饰的函数，所以需要定义一个参数来接收。文章中的例子有点小问题， test_put_post 依赖的 test_get_post 忘了写出来，它是会把获取到的条目返回的…

如果依赖多个函数的返回值，会按 depend_on 的先后顺序传递，靠近被装饰函数的会先传递，所以有几个 with_return 就定义几个参数就对了

@LXJ 不一样的， fixture 提供的是 setup teardown 的进化版，方便复用的依赖注入，但 fixture 本身不是测试，而且也无法控制测试的执行顺序。 deptest 也会支持 setup teardown 函数，但 depend_on 的核心是对测试本身的控制，而不是其所需参数的初始化过程。

@jason0916 理论上可以的，让需要 cookie 的测试 depend_on 获得 cookie 的测试，把 cookie 取出来向下传递。如果你的 http client 用的是 requests ，甚至可以用它的 session 功能来方便地发出带 cookie 的请求

@qdcanyun 是的，好的 web 框架都会有方便的测试集成方案，但对 http 服务写测试代码是一个通用需求，不应该强依赖于 web 框架，所以我才想单独解决这个问题。目前我的测试对象是一个 go 写的服务…

挺好的， lz 加油。

不过目前主流的做法是 web 框架只实现 web 层，也就是路由、中间件等工具的集合，运行时跑在某种 server 程序上，比如 gevent, tornado,twisted, uwsgi, etc. 这样非常灵活，底层可根据不同情况来选择。 lz 这个项目和 gevent 耦合太深，运用就显得有些单一了。可以考虑尝试把 app 的东西拆出来，最后生成一个 WSGI 的 application 就可以了。

另外看代码里 url 参数的支持是靠 `<param>` 这样的写法吗，感觉还是直接支持正则比较好。

你需要分账软件，比如 splitwise

@wangranche 是从这个歌单里选出来的，登陆 spotify 可以试听: https://open.spotify.com/user/novoreorx/playlist/5dDzbJwkqWO3Tbpq6F9KXR

并不是

@AWWBWG 看起来很有意思诶，和 squared 还挺像的，不同的是它是自动生成，且包含了一些其他的文字信息， squared 是主动去组织布局