即时反馈&单元测试

单元测试不仅仅是给老板带来了高质量的软件，还会让你（程序员）体验一个愉快的过程，信不？

即时反馈

人产生一个行为（做了一个动作、一件事），总是期望知道这个行为是否产生了预期的效果、达到了预期目的，以便调整行为（若未达到预期）或进行下一步（已达到预期）。

如果能马上知道，人的心理就比较轻松；如果持续这种 行为--反馈 的过程，人的心理就会有一些快感，从而让人喜欢上这个过程。这就是即时反馈的魔力

相反，如果一个行为产生之后，需要较长时间才能知道结果，那这个等待的过程中人的心理就有疑虑、有负担——悬而未决的事总是会让人产生这样的负担。如果持续面对这样的 行为--等待--反馈，就会对这个过程产生厌倦，进而抗拒。

列举一些日常生活和编程中可以用这个机制来解释的现象：

• 一个App的按钮响应很迅速，用户体验就好
• 网页加载时，loading时间太长，人就很烦躁
• 写代码时，一般是写几句之后就会编译一下，看有没有语法错误（编译型语言；或重新加载一下，看是否是预期的样子（脚本语言）
• 调试时不能设断点、不能单步调试，是不是很痛苦？

想象一下，写代码时让你“盲写”——没有调试途径，直到你完成全部功能，才给你调试的机会。这样的开发模式是不是会让人疯掉？再想一下是什么东西让你疯掉的？是不是你根本不知道你写的每一行代码有没有语法错误、逻辑对不对，这种感觉让你抓狂。好比是黑灯瞎火走路，你根本不知道下一步会踩到哪里。这是没有反馈的极端情况。

单元测试

单元测试就是为程序员创造即时反馈的一个利器。当然，调试器也是因为能即时反馈而成为开发必不可少的工具。可以说，单元测试又向前推进了一步，而且把你需要多次重复的动作给自动化了——又是一个额外的收益。

想象一下，你写每一个方法、每一个类，你都能即刻、确切知道是否达到了预期目的，那样你的心是多么轻松愉快，一切都在你的掌握中。这样持续下去，你写的软件绝不可能是“失控”的。

阻碍

• 写单元测试代码也需要时间，而且功能代码改了，测试代码也需要同步修改，需要时间。这是额外的开销。
• 要做到代码覆盖率很高（比如1:1），很不容易。