如何将PHPUnit与CodeIgniter一起使用？

Question

我已阅读和阅读有关PHPUnit,SimpleTest和其他单元测试框架的文章.它们听起来都很棒!我终于让PHPUnit与Codeigniter一起工作,感谢https://bitbucket.org/kenjis/my-ciunit/overview

现在我的问题是,我该如何使用它？

我看到的每个教程都有一些抽象的用法,如assertEquals(2, 1+1):

public function testSpeakWithParams()
{
    $hello = new SayHello('Marco');
    $this->assertEquals("Hello Marco!", $hello->speak());
}

如果我有一个输出这样一个可预测字符串的函数,那就太好了.通常我的应用程序从数据库中获取大量数据,然后在某种表中显示它.那么我该如何测试Codeigniter的控制器呢？

我想做测试驱动开发,我已经阅读了关于PHPUnits网站的教程,但是这个例子再一次看起来很抽象.我的大多数codeigniter函数都在显示数据.

是否有一本书或一本有实际应用的精彩教程和PHPUnit测试的例子？

Answer 1

您似乎理解了如何编写测试和单元测试的基本结构/语法CodeIgniter代码与测试非CI代码不应该有任何不同,所以我想关注您的潜在关注点/问题...

不久前我和PHPUnit有类似的问题.作为一个没有经过正式培训的人,我发现进入单元测试心态似乎是抽象的,不自然的.我认为这个的主要原因 - 在我的情况下,也可能是你的问题 - 是你没有专注于真正努力将你的代码中的问题分开到现在为止.

测试断言似乎是抽象的,因为大多数方法/函数可能执行几个不同的离散任务.成功的测试心态需要改变您对代码的看法.你应该停止以"它有效吗？"来定义成功.相反,你应该问,"它是否有效,它是否能与其他代码一起发挥作用,它是否以一种在其他应用程序中有用的方式设计,我能否验证它是否有效？"

例如,下面是一个简化的示例,说明您到目前为止编写代码的方式:

function parse_remote_page_txt($type = 'index')
{
  $remote_file = ConfigSingleton::$config_remote_site . "$type.php";
  $local_file  = ConfigSingleton::$config_save_path;

  if ($txt = file_get_contents($remote_file)) {
    if ($values_i_want_to_save = preg_match('//', $text)) {
      if (file_exists($local_file)) {
        $fh = fopen($local_file, 'w+');
        fwrite($fh, $values_i_want_to_save);
        fclose($fh);
        return TRUE;
      } else {
        return FALSE;
      }
  } else {
    return FALSE;
  }  
}

究竟这里发生的事情并不重要.我试图说明为什么这段代码难以测试:

• 它使用单例配置类来生成值.函数的成功取决于单例的值,当你无法用不同的值实例化新的配置对象时,如何测试这个函数在完全隔离中是否正常工作？更好的选择可能是为您的函数传递一个$config参数,该参数由您可以控制其值的配置对象或数组组成.这被广泛称为" 依赖注入 ",并且在整个互联网上讨论了这种技术.

• 注意嵌套IF语句.测试意味着您通过某种测试覆盖每个可执行行.当您嵌套IF语句时,您正在创建需要新测试路径的新代码分支.

• 最后,你看到这个函数,虽然它似乎做了一件事(解析远程文件的内容)实际上是在执行几个任务吗？如果您热心地分离您的疑虑,您的代码将变得无比可测试.一个更可测试的方法来做同样的事情将是......

class RemoteParser() {
  protected $local_path;
  protected $remote_path;
  protected $config;

  /**
   * Class constructor -- forces injection of $config object
   * @param ConfigObj $config
   */
  public function __construct(ConfigObj $config) {
    $this->config = $config;
  }

  /**
   * Setter for local_path property
   * @param string $filename
   */
  public function set_local_path($filename) {
    $file = filter_var($filename);
    $this->local_path = $this->config->local_path . "/$file.html";
  }

  /**
   * Setter for remote_path property
   * @param string $filename
   */
  public function set_remote_path($filename) {
    $file = filter_var($filename);
    $this->remote_path = $this->config->remote_site . "/$file.html";
  }

  /**
   * Retrieve the remote source
   * @return string Remote source text
   */
  public function get_remote_path_src() {
    if ( ! $this->remote_path) {
      throw new Exception("you didn't set the remote file yet!");
    }
    if ( ! $this->local_path) {
      throw new Exception("you didn't set the local file yet!");
    }
    if ( ! $remote_src = file_get_contents($this->remote_path)) {
      throw new Exception("we had a problem getting the remote file!");
    }

    return $remote_src;
  }

  /**
   * Parse a source string for the values we want
   * @param string $src
   * @return mixed Values array on success or bool(FALSE) on failure
   */
  public function parse_remote_src($src='') {
    $src = filter_validate($src);
    if (stristr($src, 'value_we_want_to_find')) {
      return array('val1', 'val2');
    } else {
      return FALSE;
    }
  }

  /**
   * Getter for remote file path property
   * @return string Remote path
   */
  public function get_remote_path() {
    return $this->remote_path;
  }

  /**
   * Getter for local file path property
   * @return string Local path
   */
  public function get_local_path() {
    return $this->local_path;
  }
}

如您所见,这些类方法中的每一个都处理可轻松测试的类的特定函数.远程文件检索是否有效？我们找到了我们试图解析的值吗？等等.突然间,这些抽象断言似乎更有用.

恕我直言,你越是深入研究测试越多,你就会意识到它更多地是关于良好的代码设计和合理的架构,而不仅仅是确保事情按预期工作.在这里,OOP的好处真正开始闪耀.您可以很好地测试过程代码,但对于具有相互依赖的部件测试的大型项目,可以实现良好的设计.我知道这可能是一些程序人员的巨魔诱饵但是哦.

你测试的越多,你就越会发现自己编写代码并问自己,"我能测试这个吗？" 如果没有,你可能会改变那里的结构.

但是,代码不必是基本的可测试的.Stubbing和mocking允许您测试外部操作,其成功或失败完全失控.您可以创建夹具来测试数据库操作以及其他任何东西.

我测试的越多,我就越发现如果我在测试某些东西时遇到困难,那很可能是因为我有一个潜在的设计问题.如果我把它弄直,它通常会导致我的测试结果中出现所有绿色条.

最后,这里有几个链接真正帮助我开始以一种测试友好的方式思考.第一个是如果你想编写可测试代码那么不该做的一个简单的列表.事实上,如果你浏览整个网站,你会发现许多有用的东西,这将有助于你在100%代码覆盖率的道路上.另一篇有用的文章是关于依赖注入的讨论.

祝好运!