推荐学习书目
› Learn Python the Hard Way
Python Sites
› PyPI - Python Package Index
› http://diveintopython.org/toc/index.html
› Pocoo
值得关注的项目
› PyPy
› Celery
› Jinja2
› Read the Docs
› gevent
› pyenv
› virtualenv
› Stackless Python
› Beautiful Soup
› 结巴中文分词
› Green Unicorn
› Sentry
› Shovel
› Pyflakes
› pytest
Python 编程
› pep8 Checker
Styles
› PEP 8
› Google Python Style Guide
› Code Style from The Hitchhiker's Guide
这是一个创建于 2927 天前的主题，其中的信息可能已经有所发展或是发生改变。
覆盖率似乎不是唯一的标准, 因为我发现即使覆盖率达到 100%, 但还是可能会存在没有发现的编码错误.
 |
1
calease 2016-04-27 10:28:34 +08:00
你说的 100%是 line coverage 吧，还有 branch coverage 呢。
另外 coverage 不用追求 100%。 60%以上不错， 80%以上很好。 |
 |
2
jeff_kit 2016-04-27 10:33:40 +08:00
通常我们一个方法会对应着 N 多个测试方法，所有的分支流转情况都有对应的方法来测试。如同楼上所说，光有覆盖不够的。
|
 |
3
Mush OP @calease 搜噶, 我知道 branch coverage, 但还是一样似乎很容易就达到 60%了. 断言的设计应该也灰常重要吧, 既没有必要每个变量都判断下, 又得尽可能的考虑到所以情况, 感觉有点不知所措. 看起来似乎没有什么 Silver Bullet 的样子吧
|
 |
4
janxin 2016-04-27 11:00:41 +08:00
这时需要做异常预判断，预估所有的异常情况。不过这个确实非常麻烦，我现在基本是靠个人经验来规避，不知道大家是怎么做的。像这种时候，比如 Golang 就是让你强制来做情况预估（嗯，一大堆的 err check ）。
coverage 的覆盖率不能只看百分比，重点还是在分支情况的覆盖，单纯追求 100%对代码质量保证不一定非常有效。 |
 |
5
darasion 2016-04-27 15:06:55 +08:00
我一般都是对这些东西写测试：
1. 我不确定是否好使的部分，比如正则匹配的各种东西，写完之后我得确认一下它是否写对了 2. 之前出过 bug 的部分，补充 case ，下次再改的时候就放心了 3. 设计良好的代码，这部分就是属于自我陶醉了.... 看到测试通过心情会很愉快。 |
Select Language