一枚程序员眼中的单元测试

Posted 2022-11-25 袁慎建@ThoughtWorks

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了一枚程序员眼中的单元测试相关的知识，希望对你有一定的参考价值。

论测试的重要性

如今程序员群体赶上了中国最庞大的农民群体，大街上随便抓一把，十有八九是程序员，还一个刚从某国企离职报名参加软件培训班。我想码农的称号或许就是这么来的吧。

在外行人看来，程序员是一个成天对着电脑倒腾着代码、看着Terminal上行云流水般的打印、过着不修边幅的日子外加超负荷的码农。

在内行人看来，程序员是一个成天面对QA的"质疑"、PM的"夺命催"以及DEVs的"吐槽"，扛着身心压力的苦行僧。

在我看来，程序员应该是：

手持神剑，心怀善念，胸有成竹、有理有据并且合情合理地跟QA、PM、DEV斗智斗勇的战士。

要摆脱QA的质疑、DEVs的吐槽以及PM的夺命催，除了那些不容易掌控的客观因素，我们可以从自身发力，加强自身的"核心肌群"，呈现出自己的应有的专业态度，编写出高质量的代码，从而促成高质量的交付。

如何交付高质量的代码？

首先，我们可以摆出苦行僧的心态，平日里练就一身好把式：如Clean Code、Refactor、OOD及FOP。即便这样，牛逼哄哄的程序员也不敢说自己的代码百分之百没有缺陷。

怎么办，两个参考原则：

编写完代码多问自己一句：“真的可靠地完成目标了吗？” 怎么问，写个测试来提问。这便是 测试覆盖。
编写代码之前先问自己一句：“怎么样才算完成目标了呢？” 怎么问，同样写个测试来提问。这便是 TDD + 测试覆盖。

测试能做什么

要知道测试能做什么，首先我们需要知道测试是什么（它在测什么）？它能给我们带来什么价值？以及人力成本那么昂贵，我们为什么还要花时间去编写这些上不了产品的测试代码？

程序员总喜欢倒腾点代码来开始一个话题：

public class StringUtils 
    public static String toUpperCase(String source) 
        if (source == null) 
            return null;
        
        return source.toUpperCase();
    



class StringUtilsTest 
    @Test
    void convert_to_upper_case() throws Exception 
        assertThat(StringUtils.toUpperCase("unit-test"), is("UNIT-TEST"));

这一小段测试代码所做的事情是在验证StringUtils#toUpperCase方法的功能正确性。

顺便用一句话来形容单元测试：

开发人员编写一小段代码，用于检验被检测代码的一个很小的、很明确的功能是否正确。

图片来自：https://martinfowler.com/bliki/TestPyramid.html

广义上的测试并不总是像上面这段代码这么简单，熟为人知的测试金字塔将测试分为三大类，单元测试位于测试金字塔底端，旨在传达单元测试应该来得更凶猛一些，而它们正是由开发人员亲手编写出来。本文也是围绕单元测试来开展。

测试的价值何在

经常听开发人员说："我对我的代码非常有信心。"理由往往充分且单一：单元测试是老大，老大罩着我不怕。（当然，专业的QA始终能发现DEV很难察觉到的Defect，难免会惊起一脸狐疑：*老大不灵了吗！*回首代码，觉漏某一Case）。

所以单元测试能够增强你写代码的信心。都说自信是成功者必不可少的特质。当你对代码充满信心之后，你的潜能无形中被激发（你会发现你敲代码的速度都会变快），这样你工作效率的提高促使你更加轻松地完成工作。身心受益便会产生一连串良性的"蝴蝶效应"。

测试的两个无形价值就体现出来了：

增强我们写代码的信心。
让我们更加轻松的完成工作，身心收益。

再来说说有形的代码。缺陷减少了则证明你的代码质量提高了，代码质量衡量指标总离不开可读性、可扩展性、可维护性。这三个指标的增强反映了良好的代码整洁度、OO设计、模块化等。实践证明，这些良好的设计往往不是一蹴而就的，而当你为一个类或方法编写单元测试却举步维艰的时候，你就应该考虑去改良你的设计了。