首页   注册   登录
 LXJ 最近的时间轴更新
LXJ

LXJ

V2EX 第 7846 号会员,加入于 2011-04-12 13:27:08 +08:00
17 S 5 B
LXJ 最近回复了
element 好像已经不维护了
2016-06-06 17:55:24 +08:00
回复了 reorx 创建的主题 Python 发布一个支持依赖关系组织的测试框架
@reorx 『其实如果想确保 fixture 的东西都是正确的,也可以在里面写一些 assert 语句确保正确,只是它不叫 testcase 而已』 这句话其实对应着主贴提到的 『严格遵循单元测试思想中问题: 一个是测试的目的发生了改变、另一个是让代码变得非常臃肿』臃肿的问题在 fixture 的写法上感觉还好, 还有也对应着『 setup 中放入数据库操作的代码却让 model 层工作正常成为了先决条件』,一般在构建 fixture 时,也会在调试时验证 fixture 是否正确,只是没有像 testcase 那样加一些 assert 语句,这点工作和单独写成一个 testcase 并没有本质的分别;


『因为「对测试用例的执行顺序有要求」这样的事情在很多场景下是存在的』,其实个人觉得即使是要测试的流程变得很长,也是一个单元测试,只是测试的单元变得大了而已,按照 『互相有依赖的测试其实可以看做一个测试组』说法,感觉 deptest 是把这个长的测试流程分拆了组,如果能整合到 nose 或 pytest 里面感觉会个吸引人的特性 :)
2016-06-06 12:32:09 +08:00
回复了 reorx 创建的主题 Python 发布一个支持依赖关系组织的测试框架
@reorx 关于『但 fixture 本身不是测试,而且也无法控制测试的执行顺序』这句话,其实如果想确保 fixture 的东西都是正确的,也可以在里面写一些 assert 语句确保正确,只是它不叫 testcase 而已;而且单元测试里面,不同测试用例间理论上一开始假想可以单独运行的,并不受其他单元测试用例的影响,所以执顺序并非一个很重要特性。

纯想象性质猜想一下,如果采用 deptest 的写法,可能因为前面某个 testcase failed 了,导致后面的依赖它的测试也多 failed 了,开发者必须找到最底层的依赖,先 fix 了,再开始调试上层的测试是否正常;测试用例多了后,感觉也会带来额外的 debug 成本。
2016-06-04 23:27:11 +08:00
回复了 reorx 创建的主题 Python 发布一个支持依赖关系组织的测试框架
上面实现的功能感觉 Pytest 已经提供了一个类似的的机制了: https://pytest.org/latest/fixture.html 而且控制依赖的粒度可以做到很细。
2015-12-29 21:30:46 +08:00
回复了 bitbegin 创建的主题 NGINX 老罗提到的 openresty 是干啥的?就是 nginx 打个包?
2015-09-12 10:37:59 +08:00
回复了 FocusFox 创建的主题 互联网 吐槽一下多看客户端,体验跟 X 了狗一样!!!
之前用多看 web 端看一本书,体验很糟糕,复制文字不能用键盘常用快捷键,必须选中后,点击他们的自定义菜单,再点击复制,效率很低;而且长时间打开 web 端,还会假死。感觉他们自己都不用自己产品似的。跪。
2015-07-02 22:06:13 +08:00
回复了 phoenixlzx 创建的主题 Arch Arch Linux 中文社区 2015 社区活动
赞活动~
关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1096 人在线   最高记录 5168   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 10ms · UTC 21:16 · PVG 05:16 · LAX 14:16 · JFK 17:16
♥ Do have faith in what you're doing.