zoukankan      html  css  js  c++  java
  • 第一节 理解单元测试

           在查看代码之前,最好提一下编写单元测试和使用单元测试的一些基本信息和规则。 记住这些基本规则并理解单元测试的重点非常重要。 单元测试不仅仅是一个很好的功能,而且是任何正规软件项目中绝对必要的部分。

           1.什么是单元测试

            一个简单的问题,什么是单元测试? 单元测试是在已知的上下文中使用已知的输入去执行另一段代码(函数/方法)的代码,将输出的结果与预期的结果进行比较, 这也称为断言。 以下代码片段是最简单的断言,验证一加一等于二,函数是否按预期的运行:

    function sum($a, $b)
    {
    return $a + $b;
    }
    $this->assertEquals(2, sum(1, 1));

      2.断言(Assertions)

      断言是单元测试的核心和灵魂。一个断言往往也伴随着一定的约束。例如,你的 assertThat值必须符合约束。一个用于解释assertThat如何运行的优秀示例就是PHPUnit本身自带的一个很简单的断言 —— assertTrue() 。 代码如下:

    public static function assertTrue($condition, $message = '')
    {
        self::assertThat($condition, self::isTrue(), $message);
    }

           以下是基本和最常用的断言:

    • assertTrue():这将验证条件是否为真
    • assertFalse():这将验证条件是否为false
    • assertEquals():它验证预期值和实际值是否相等,与PHP比较运算符==相同
    • assertSame():这类似于assertEquals(),但它检查值是否相同,与===运算符的方式相同
    • assertNull():这将验证该值是否为null
    • assertEmpty():这验证值是空的,但它使用PHP函数empty(),这意味着空可以是false,null,'',array()

    但PHPUnit有许多不同的内置断言。 您可以在http://phpunit.de/manual/3.7/en/appendixes.assertions.html上的官方文档中找到这些断言的完整列表。但是如果您需要更多,可以通过扩展PHPUnit_Framework_Constraint类来创建自己的断言。

           3.单元测试的重要性

       单元测试使我们相信编写的代码可以按预期工作,并且它是开发人员可以依赖的可靠部分。 将代码分解为小的独立单元可以降低代码与另一段代码交互时引入错误的风险。 如果您需要花费和修改应用程序而不必担心更改的任何意外后果,这是最好的投资。 它也可以是一个很好的文档来描述代码的设计方式和应该做的事情。 另一个原因是重构。 在没有测试的情况下改变复杂的代码就像进入雷区一样。

           4.测试所有可能的场景

            测试所有可能的场景会很好,但考虑一个函数,如下面的代码片段所示:

    function plusOne($a)
    {
        return 1 + $a;
    }

           PHP是一种松散类型的语言,你可以有很多场景。 但它通常是足以覆盖最期望或最重要的场景以及一些意想不到的场景(在我们的例子中,$ a可以是NULL或FALSE)

           但是你应该尝试的是测试尽可能多的代码,覆盖所有的if else 以及case 语句。尝试通过测试边缘情况来假设最坏的情况。 重要的是不仅要测试正面情况,获得预期结果,还要测试负面情况,以验证在抛出意外输入或异常时代码不会中断。

           5.什么是一个好的测试?

            以下是一些对任何单元测试有效的通用规则,而不仅仅是PHPUnit:

    • 独立:每个测试都需要独立于其他测试和环境运行。
    • 快速:要进行有用的测试并且能够尽可能频繁地运行它们(例如,作为提前或提交后的挂钩),测试需要快速。
    • 可重复:您应该能够根据需要多次运行测试并获得相同的结果。
    • 保持最新:测试编写一次,但代码可以更改或扩展。 如果你不打算更新测试,最初的测试投资只会浪费时间和金钱。 规则是,无论谁破坏了测试,都会修复测试。
    • 简短:测试应该只是几行 - 易于阅读和理解。
    • 弹性:一旦编写,测试不应改变,直到测试类/方法的行为发生变化。

          6.什么时候写测试?

           拥有100%的代码覆盖率(测试的代码量,但不一定是100%的代码覆盖率,这也意味着测试所有可能性)会很好。通常,更好的覆盖率意味着更好的质量项目。 检查GitHub上的几个开源项目,看看他们有多少测试,这可以让你了解这些项目的质量,这些项目的使用频率并不重要。 广泛使用的系统并不自动意味着高质量的代码。

           但更重要的是养成编写测试的习惯。 您可以尝试以测试为导向的开发方法,您可以将您的类想象为没有实现的接口,只是说明每个方法应该如何工作。 然后编写测试,准确描述您的期望,然后实现编写所需功能的接口,测试将验证它是否符合您的预期。

           第二种方法是编写类或函数,然后使用书面测试对其进行测试以验证功能。 规则应该是你在编写代码的同一天编写测试,因为以后你不会这样做,因为你将专注于其他事情。 绝对有必要让单元测试涵盖整个核心功能。这是必备功能。

  • 相关阅读:
    初探 Redis 客户端 Lettuce:真香!
    vscode 代码中查找并替换为换行符
    Jenkins Kubernetes插件添加 云
    Jenkins kubernetes插件的原理
    jenkins pipeline实现自动构建并部署至k8s
    python3 requests中的 stream参数
    rsync 开启用户密码认证
    rancher1版本 基本使用
    nginx http跳https
    sed合并多条指令修改文本
  • 原文地址:https://www.cnblogs.com/mysic/p/9434417.html
Copyright © 2011-2022 走看看