LXJ

element 好像已经不维护了

@reorx 『其实如果想确保 fixture 的东西都是正确的，也可以在里面写一些 assert 语句确保正确，只是它不叫 testcase 而已』 这句话其实对应着主贴提到的 『严格遵循单元测试思想中问题: 一个是测试的目的发生了改变、另一个是让代码变得非常臃肿』臃肿的问题在 fixture 的写法上感觉还好， 还有也对应着『 setup 中放入数据库操作的代码却让 model 层工作正常成为了先决条件』，一般在构建 fixture 时，也会在调试时验证 fixture 是否正确，只是没有像 testcase 那样加一些 assert 语句，这点工作和单独写成一个 testcase 并没有本质的分别；


『因为「对测试用例的执行顺序有要求」这样的事情在很多场景下是存在的』，其实个人觉得即使是要测试的流程变得很长，也是一个单元测试，只是测试的单元变得大了而已，按照 『互相有依赖的测试其实可以看做一个测试组』说法，感觉 deptest 是把这个长的测试流程分拆了组，如果能整合到 nose 或 pytest 里面感觉会个吸引人的特性 :)

@reorx 关于『但 fixture 本身不是测试，而且也无法控制测试的执行顺序』这句话，其实如果想确保 fixture 的东西都是正确的，也可以在里面写一些 assert 语句确保正确，只是它不叫 testcase 而已；而且单元测试里面，不同测试用例间理论上一开始假想可以单独运行的，并不受其他单元测试用例的影响，所以执顺序并非一个很重要特性。

纯想象性质猜想一下，如果采用 deptest 的写法，可能因为前面某个 testcase failed 了，导致后面的依赖它的测试也多 failed 了，开发者必须找到最底层的依赖，先 fix 了，再开始调试上层的测试是否正常；测试用例多了后，感觉也会带来额外的 debug 成本。

上面实现的功能感觉 Pytest 已经提供了一个类似的的机制了： https://pytest.org/latest/fixture.html 而且控制依赖的粒度可以做到很细。

这里有个详细的介绍：[OpenResty 的现状、趋势、使用及学习方法]( http://mp.weixin.qq.com/s?__biz=MzAwMDU1MTE1OQ==&mid=402261263&idx=1&sn=7b771e13eb978b0ee551596ba73165e9&scene=2&srcid=1209KVyaEG7Jf1LwuSlsdk8C&from=timeline&isappinstalled=0#wechat_redirect)

之前用多看 web 端看一本书，体验很糟糕，复制文字不能用键盘常用快捷键，必须选中后，点击他们的自定义菜单，再点击复制，效率很低；而且长时间打开 web 端，还会假死。感觉他们自己都不用自己产品似的。跪。