如何能更快的或者说更深入人心的理解单元测试, UnitTest 之类的... ?

打 Log 调试是正确姿势，相比单步调试好多了。
至于 TDD ，那不是调试。

TDD 是开发流程。现在还有一种做法是 BDD ，我个人比较偏向 BDD 。

@slixurd
@msg7086

恩 看来先从 logging 开始了..

你只需要 [Python koans - Learn Python through TDD]( https://github.com/gregmalcolm/python_koans)

@slixurd 那调试完呢？ logging 删掉吗？ 我发现 github 上面很多都没有 logging 。(git repo 里面搜索 import logging ，结果很少。)

@billgreen1
应用里的 logging 一般不删，上线的时候就把等级提高就行了，出问题的时候就指着这个救命的……

回楼主：
print 是最原始、往往也是最有效的 debug 方式
ut 只是验证自己的代码能跑、逻辑正常、附带检查覆盖率的
正好我这里有个笔记，你可以参考一下
https://mengzhuo.org/Django%E8%B0%83%E8%AF%95%E6%96%B9%E6%B3%95%E4%B8%89%E6%9E%9A.html

TDD 的难点在于： 1 ，小步前进； 2 ，重构
小步前进做得好的话，你会发现连 print 调试都不需要。 unit test 的结果已经足够判断错误的位置了。
如果小步前进做不好，很快会陷入长时间无法通过测试。开发进程停滞
如果对重构，代码味道等掌握的不不够，会发现长时间的反复增加同质行为，却无法改进代码设计
TDD 并不是简单的流程，只要听听步骤，它需要进行一定的练习才能真正掌握。严格来说这种练习是无止境的，因为重构涉及的就是最细节的设计，而设计能力永远都有提高的空间。

如果真的感兴趣的话可以平时做些题目。
推荐 http://cyber-dojo.org, 在上面可以选各种语言和各种练习题目，进行 TDD 开发。每次测试系统都会保留代码历史。
这里有篇文章介绍 http://coding-is-like-cooking.info/2013/01/setting-up-a-new-code-kata-in-cyber-dojo/

回答你的问题的时候，我本想在这个站点上找些 Python 的代码，却没有发现合适的。所以就做了个没做过的练习。题目的是把数字转换为英文名字：比如 310 --> three hundred and ten
打开链接后点页面上面的绿色或者红色圆点可以查看每次测试的记录。
http://cyber-dojo.org/kata/edit/F53C57?avatar=antelope

我对 Python 不是很熟，这道题以前也没有自己做过。总共用时约 2 个小时，测试了 90 多次。
从历史记录中可以看到我犯过很多低级错误，也可以看到是怎么样利用 TDD 逐步解决问题的。

@asj 我感觉这样一个案例诚实能帮助我了解这块的困扰 感谢发送 ed. 再次口头感谢一次