《Clean Code》笔记

避免在代码中使用魔法数字,再次之前我一直认为数字的出现影响对代码的可读性。

刚才在看《Clean Code》的时候,才了解到,如果代码中包含了大量的数字,会造成我们搜索上范围的扩大。

也许我们需要搜索一个标签代码,内容是的数字,但是你输入这个数字,出现了许多其他类中的魔法数字,大大降低了我们在代码搜索中的效率。


有些简单的条件判断,并不需要一个方法单独写他们,可以创建一个简单的BOOL类型,对这个条件进行声明,这样在接下来的if判断中,我们会看到很清晰的条件。


测试应该保证5条原则

  • 快速
    测试应该够快。

测试如果允许缓慢,你就不会想要频繁的运行它。如果不频繁测试,就无法尽早的发现问题。

  • 独立
    测试应该相互独立。

某个测试不应为下一个测试设定提交。应该可单独运行任何一个测试代码,当测试相互依赖时,其中一个没通过就会导致相关联的测试失败,造成问题难以确定,隐藏了下级错误。

  • 可重复
    测试应当在任何环境中重复通过。

如果测试不恩能够在任意环境中重复,你就总会有解释其失败的接口。当环境条件不具备时,你也无法运行测试。

  • 自足验证
    测试应该有布尔值输出。(个人认为这个非常非常重要,在代码编写过程中,有重要结果返回的地方,我们都应该有个BOOL值来验证)

无论通过或失败,你不应该通过查看日志的形式来确认测试是否通过。不应该手工的对比两个不同文本文件来确认是否通过测试。如果测试不能自足验证,对失败的判断就会变得依赖主观,而运行测试需要更长的手工操作时间。

  • 及时
    测试应该及时编写。

单元测试应该恰好在使其通过的生产代码之前编写。如果在编写生产代码之后编写测试,你会发现生产代码难以测试。你可能会认为某些生产代码本身难以测试,就不会设计可测试的代码。

 

测试相比起业务代码的编写一般来说会更难一些,很多时候你会发现有
些代码是“无法测试”的,因为代码之间存在较高的耦合程度,因此绕不
开对于其他类的依赖,来对某个类单独测试其正确性。我们不能依赖于一
个没有经过测试的类来对另一个需要测试的类进行测试,如果这么做了,
我们便无法确定测试的结果是否正是按我们的需要得到的(不能排除测试
成功,但是其实是因为未测试的依赖类恰好失败了而恰巧得到的正确结果
的可能性)。

—摘自Onevcat博客(http:http://onevcat.com/2014/05/kiwi-mock-stub-test/)