创建可测试和可维护的 PHP 代码

框架提供了快速应用程序开发的工具，但通常会随着您创建功能的速度而增加技术债务。当可维护性不是开发人员有目的地关注的焦点时，就会产生技术债务。由于缺乏单元测试和结构，未来的更改和调试成本高昂。

以下是如何开始构建代码以实现可测试性和可维护性 - 并节省您的时间。

---

我们将（松散地）覆盖

1. 干燥
2. 依赖注入
3. 接口
4. 容器
5. 使用 PHPUnit 进行单元测试

让我们从一些人为但典型的代码开始。这可能是任何给定框架中的模型类。

class User {

public function getCurrentUser()
{
    $user_id = $_SESSION['user_id'];

    $user = App::db->select('id, username')
                    ->where('id', $user_id)
                    ->limit(1)
                    ->get();

    if ( $user->num_results() > 0 )
    {
            return $user->row();
    }

    return false;
}

}

此代码可以工作，但需要改进：

1. 这是不可测试的。
   • 我们依赖 $_SESSION 全局变量。单元测试框架（例如 PHPUnit）依赖于命令行，其中 $_SESSION 和许多其他全局变量不可用。
   • 我们依赖数据库连接。理想情况下，在单元测试中应避免实际的数据库连接。测试是关于代码，而不是数据。
2. 此代码的可维护性并不理想。例如，如果我们更改数据源，则需要更改应用程序中使用的每个 App::db 实例中的数据库代码。另外，如果我们不想要当前用户的信息怎么办？

尝试的单元测试

这里尝试为上述功能创建单元测试。

class UserModelTest extends PHPUnit_Framework_TestCase {

    public function testGetUser()
    {
        $user = new User();

        $currentUser = $user->getCurrentUser();

        $this->assertEquals(1, $currentUser->id);
    }

}

让我们检查一下。首先，测试将失败。 User 对象中使用的 $_SESSION 变量在单元测试中不存在，因为它在命令行中运行 PHP。

其次，没有数据库连接设置。这意味着，为了完成这项工作，我们需要引导我们的应用程序以获得 App 对象及其 db 对象。我们还需要一个可用的数据库连接来进行测试。

为了使这个单元测试工作，我们需要：

1. 为我们的应用程序中运行的 CLI (PHPUnit) 设置配置
2. 依赖数据库连接。这样做意味着依赖与我们的单元测试分开的数据源。如果我们的测试数据库没有我们期望的数据怎么办？如果我们的数据库连接很慢怎么办？
3. 依赖引导的应用程序会增加测试的开销，从而显着减慢单元测试的速度。理想情况下，我们的大多数代码都可以独立于所使用的框架进行测试。

那么，让我们开始讨论如何改进这一点。

---

保持代码干燥

在这个简单的上下文中，检索当前用户的函数是不必要的。这是一个人为的示例，但本着 DRY 原则的精神，我选择进行的第一个优化是概括此方法。

class User {

    public function getUser($user_id)
    {
        $user = App::db->select('user')
                        ->where('id', $user_id)
                        ->limit(1)
                        ->get();

        if ( $user->num_results() > 0 )
        {
            return $user->row();
        }

        return false;
    }

}

这提供了一种我们可以在整个应用程序中使用的方法。我们可以在调用时传入当前用户，而不是将该功能传递给模型。当代码不依赖其他功能（例如会话全局变量）时，代码更加模块化和可维护。

但是，这仍然无法按预期进行测试和维护。我们仍然依赖数据库连接。

---

依赖注入

让我们通过添加一些依赖注入来帮助改善这种情况。当我们将数据库连接传递到类中时，我们的模型可能如下所示。

class User {

    protected $_db;

    public function __construct($db_connection)
    {
        $this->_db = $db_connection;
    }

    public function getUser($user_id)
    {
        $user = $this->_db->select('user')
                        ->where('id', $user_id)
                        ->limit(1)
                        ->get();

        if ( $user->num_results() > 0 )
        {
            return $user->row();
        }

        return false;
    }

}

现在，我们的 User 模型的依赖项已经提供了。我们的类不再假定某个数据库连接，也不再依赖于任何全局对象。

至此，我们的类就基本可以测试了。我们可以传入我们选择的数据源（大部分）和用户 ID，并测试该调用的结果。我们还可以切换单独的数据库连接（假设两者都实现相同的检索数据的方法）。酷。

让我们看看单元测试可能是什么样子。

<?php

use Mockery as m;
use Fideloper\User;

class SecondUserTest extends PHPUnit_Framework_TestCase {

    public function testGetCurrentUserMock()
    {
        $db_connection = $this->_mockDb();

        $user = new User( $db_connection );

        $result = $user->getUser( 1 );

        $expected = new StdClass();
        $expected->id = 1;
        $expected->username = 'fideloper';

        $this->assertEquals( $result->id, $expected->id, 'User ID set correctly' );
        $this->assertEquals( $result->username, $expected->username, 'Username set correctly' );
    }

    protected function _mockDb()
    {
        // "Mock" (stub) database row result object
        $returnResult = new StdClass();
        $returnResult->id = 1;
        $returnResult->username = 'fideloper';

        // Mock database result object
        $result = m::mock('DbResult');
        $result->shouldReceive('num_results')->once()->andReturn( 1 );
        $result->shouldReceive('row')->once()->andReturn( $returnResult );

        // Mock database connection object
        $db = m::mock('DbConnection');

        $db->shouldReceive('select')->once()->andReturn( $db );
        $db->shouldReceive('where')->once()->andReturn( $db );
        $db->shouldReceive('limit')->once()->andReturn( $db );
        $db->shouldReceive('get')->once()->andReturn( $result );

        return $db;
    }

}

我在此单元测试中添加了一些新内容：Mockery。 Mockery 允许您“模拟”（伪造）PHP 对象。在本例中，我们正在模拟数据库连接。通过我们的模拟，我们可以跳过测试数据库连接并简单地测试我们的模型。

想要了解有关 Mockery 的更多信息吗？

在本例中，我们正在模拟 SQL 连接。我们告诉模拟对象期望调用 select、where、limit 和 get 方法。我返回 Mock 本身，以反映 SQL 连接对象如何返回自身 ($this)，从而使其方法调用“可链接”。请注意，对于 get 方法，我返回数据库调用结果 - 填充了用户数据的 stdClass 对象。

这解决了一些问题：

1. 我们仅测试我们的模型类。我们还没有测试数据库连接。
2. 我们能够控制模拟数据库连接的输入和输出，因此可以可靠地测试数据库调用的结果。我知道由于模拟数据库调用，我将获得用户 ID“1”。
3. 我们不需要引导我们的应用程序，也不需要提供任何配置或数据库来进行测试。

我们还可以做得更好。这就是它变得有趣的地方。

---

接口

为了进一步改进这一点，我们可以定义并实现一个接口。考虑以下代码。

interface UserRepositoryInterface {
    public function getUser($user_id);
}

class MysqlUserRepository implements UserRepositoryInterface {

    protected $_db;

    public function __construct($db_conn)
    {
        $this->_db = $db_conn;
    }

    public function getUser($user_id)
    {
        $user = $this->_db->select('user')
                    ->where('id', $user_id)
                    ->limit(1)
                    ->get();

        if ( $user->num_results() > 0 )
        {
            return $user->row();
        }

        return false;
    }

}

class User {

    protected $userStore;

    public function __construct(UserRepositoryInterface $user)
    {
        $this->userStore = $user;
    }

    public function getUser($user_id)
    {
        return $this->userStore->getUser($user_id);
    }

}

这里发生了一些事情。

1. 首先，我们为用户数据源定义一个接口。这定义了 addUser() 方法。
2. 接下来，我们实现该接口。在本例中，我们创建一个 MySQL 实现。我们接受一个数据库连接对象，并使用它从数据库中获取用户。
3. 最后，我们在 User 模型中强制使用实现 UserInterface 的类。这样可以保证数据源始终有一个可用的 getUser() 方法，无论使用哪个数据源来实现 UserInterface。

请注意，我们的 User 对象类型提示 UserInterface 在其构造函数中。这意味着实现 UserInterface 的类必须传递到 User 对象中。这是我们所依赖的保证 - 我们需要 getUser 方法始终可用。

这样做的结果是什么？

• 我们的代码现在完全可测试。对于User类，我们可以轻松地模拟数据源。 （测试数据源的实现将是单独的单元测试的工作）。
• 我们的代码更加易于维护。我们可以切换不同的数据源，而无需更改整个应用程序的代码。
• 我们可以创建任何数据源。 ArrayUser、MongoDbUser、CouchDbUser、MemoryUser 等
• 如果需要，我们可以轻松地将任何数据源传递到我们的 User 对象。如果您决定放弃 SQL，则只需创建一个不同的实现（例如 MongoDbUser）并将其传递到您的 User 模型中。

我们还简化了单元测试！

<?php

use Mockery as m;
use Fideloper\User;

class ThirdUserTest extends PHPUnit_Framework_TestCase {

    public function testGetCurrentUserMock()
    {
        $userRepo = $this->_mockUserRepo();

        $user = new User( $userRepo );

        $result = $user->getUser( 1 );

        $expected = new StdClass();
        $expected->id = 1;
        $expected->username = 'fideloper';

        $this->assertEquals( $result->id, $expected->id, 'User ID set correctly' );
        $this->assertEquals( $result->username, $expected->username, 'Username set correctly' );
    }

    protected function _mockUserRepo()
    {
        // Mock expected result
        $result = new StdClass();
        $result->id = 1;
        $result->username = 'fideloper';

        // Mock any user repository
        $userRepo = m::mock('Fideloper\Third\Repository\UserRepositoryInterface');
        $userRepo->shouldReceive('getUser')->once()->andReturn( $result );

        return $userRepo;
    }

}

我们已经完全取消了模拟数据库连接的工作。相反，我们只是模拟数据源，并告诉它当调用 getUser 时要做什么。

但是，我们仍然可以做得更好！

---

容器

考虑我们当前代码的用法：

// In some controller
$user = new User( new MysqlUser( App:db->getConnection("mysql") ) );
$user->id = App::session("user->id");

$currentUser = $user->getUser($user_id);

我们的最后一步是引入容器。容器。在上面的代码中，我们需要创建并使用一堆对象来获取当前用户。此代码可能散布在您的应用程序中。如果您需要从 MySQL 切换到 MongoDB，您仍然需要编辑上述代码出现的每个位置。那几乎不是干的。容器可以解决这个问题。

容器只是“包含”一个对象或功能。它类似于应用程序中的注册表。我们可以使用容器自动实例化一个新的 User 对象以及所有需要的依赖项。下面，我使用 Pimple，一个流行的容器类。

// Somewhere in a configuration file
$container = new Pimple();
$container["user"] = function() {
    return new User( new MysqlUser( App:db->getConnection('mysql') ) );
}

// Now, in all of our controllers, we can simply write:
$currentUser = $container['user']->getUser( App::session('user_id') );

我已将 User 模型的创建移至应用程序配置中的一个位置。结果是：

1. 我们的代码保持干燥。 User 对象和选择的数据存储在我们应用程序的一个位置定义。
2. 我们可以将 User 模型从使用 MySQL 切换到 ONE 位置中的任何其他数据源。这更易于维护。

---

最终想法

在本教程的过程中，我们完成了以下任务：

1. 保持我们的代码干燥且可重用
2. 创建了可维护的代码 - 如果需要，我们可以在整个应用程序的一个位置切换对象的数据源
3. 使我们的代码可测试 - 我们可以轻松模拟对象，而无需依赖引导我们的应用程序或创建测试数据库
4. 了解如何使用依赖注入和接口来创建可测试和可维护的代码
5. 了解容器如何帮助我们的应用程序更易于维护

我相信您已经注意到，我们以可维护性和可测试性的名义添加了更多代码。可以对这种实现提出强有力的论据：我们正在增加复杂性。事实上，这需要项目的主要作者和合作者对代码有更深入的了解。

但是，技术债务总体减少远远超过了解释和理解的成本。

• 代码的可维护性大大提高，可以在一个位置而不是多个位置进行更改。
• 能够（快速）进行单元测试将大幅减少代码中的错误 - 特别是在长期或社区驱动的（开源）项目中。
• 提前做额外的工作将节省时间并减少以后的麻烦。

资源

您可以使用 Composer 轻松地将 Mockery 和 PHPUnit 包含到您的应用程序中。将这些添加到 composer.json 文件中的“require-dev”部分：

"require-dev": {
    "mockery/mockery": "0.8.*",
    "phpunit/phpunit": "3.7.*"
}

然后，您可以按照“dev”要求安装基于 Composer 的依赖项：

$ php composer.phar install --dev

在 Nettuts+ 上了解有关 Mockery、Composer 和 PHPUnit 的更多信息。

• 嘲笑：更好的方法
• 使用 Composer 轻松进行包管理
• 测试驱动的 PHP

对于 PHP，请考虑使用 Laravel 4，因为它特别利用了容器和此处介绍的其他概念。

感谢您的阅读！

以上是创建可测试和可维护的 PHP 代码的详细内容。更多信息请关注PHP中文网其他相关文章！