框架提供了快速应用程序开发的工具，但通常会随着您创建功能的速度而增加技术债务。当可维护性不是开发人员有目的地关注的焦点时，就会产生技术债务。由于缺乏单元测试和结构，未来的更改和调试成本高昂。
以下是如何开始构建代码以实现可测试性和可维护性 - 并节省您的时间。
我们将（松散地）覆盖干燥依赖注入接口容器使用 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;}}
此代码可以工作，但需要改进：
这是不可测试的。我们依赖 $_session 全局变量。单元测试框架（例如 phpunit）依赖于命令行，其中 $_session 和许多其他全局变量不可用。我们依赖数据库连接。理想情况下，在单元测试中应避免实际的数据库连接。测试是关于代码，而不是数据。此代码的可维护性并不理想。例如，如果我们更改数据源，则需要更改应用程序中使用的每个 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 对象。我们还需要一个可用的数据库连接来进行测试。
为了使这个单元测试工作，我们需要：
为我们的应用程序中运行的 cli (phpunit) 设置配置依赖数据库连接。这样做意味着依赖与我们的单元测试分开的数据源。如果我们的测试数据库没有我们期望的数据怎么办？如果我们的数据库连接很慢怎么办？依赖引导的应用程序会增加测试的开销，从而显着减慢单元测试的速度。理想情况下，我们的大多数代码都可以独立于所使用的框架进行测试。那么，让我们开始讨论如何改进这一点。
保持代码干燥在这个简单的上下文中，检索当前用户的函数是不必要的。这是一个人为的示例，但本着 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，并测试该调用的结果。我们还可以切换单独的数据库连接（假设两者都实现相同的检索数据的方法）。酷。
让我们看看单元测试可能是什么样子。
<?phpuse 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 对象。
这解决了一些问题：
我们仅测试我们的模型类。我们还没有测试数据库连接。我们能够控制模拟数据库连接的输入和输出，因此可以可靠地测试数据库调用的结果。我知道由于模拟数据库调用，我将获得用户 id“1”。我们不需要引导我们的应用程序，也不需要提供任何配置或数据库来进行测试。我们还可以做得更好。这就是它变得有趣的地方。
接口为了进一步改进这一点，我们可以定义并实现一个接口。考虑以下代码。
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); }}
这里发生了一些事情。
首先，我们为用户数据源定义一个接口。这定义了 adduser() 方法。接下来，我们实现该接口。在本例中，我们创建一个 mysql 实现。我们接受一个数据库连接对象，并使用它从数据库中获取用户。最后，我们在 user 模型中强制使用实现 userinterface 的类。这样可以保证数据源始终有一个可用的 getuser() 方法，无论使用哪个数据源来实现 userinterface。请注意，我们的 user 对象类型提示 userinterface 在其构造函数中。这意味着实现 userinterface 的类必须传递到 user 对象中。这是我们所依赖的保证 - 我们需要 getuser 方法始终可用。
这样做的结果是什么？
我们的代码现在完全可测试。对于user类，我们可以轻松地模拟数据源。 （测试数据源的实现将是单独的单元测试的工作）。我们的代码更加易于维护。我们可以切换不同的数据源，而无需更改整个应用程序的代码。我们可以创建任何数据源。 arrayuser、mongodbuser、couchdbuser、memoryuser 等如果需要，我们可以轻松地将任何数据源传递到我们的 user 对象。如果您决定放弃 sql，则只需创建一个不同的实现（例如 mongodbuser）并将其传递到您的 user 模型中。我们还简化了单元测试！
<?phpuse 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 模型的创建移至应用程序配置中的一个位置。结果是：
我们的代码保持干燥。 user 对象和选择的数据存储在我们应用程序的一个位置定义。我们可以将 user 模型从使用 mysql 切换到 one 位置中的任何其他数据源。这更易于维护。最终想法在本教程的过程中，我们完成了以下任务：
保持我们的代码干燥且可重用创建了可维护的代码 - 如果需要，我们可以在整个应用程序的一个位置切换对象的数据源使我们的代码可测试 - 我们可以轻松模拟对象，而无需依赖引导我们的应用程序或创建测试数据库了解如何使用依赖注入和接口来创建可测试和可维护的代码了解容器如何帮助我们的应用程序更易于维护我相信您已经注意到，我们以可维护性和可测试性的名义添加了更多代码。可以对这种实现提出强有力的论据：我们正在增加复杂性。事实上，这需要项目的主要作者和合作者对代码有更深入的了解。
但是，技术债务总体减少远远超过了解释和理解的成本。
代码的可维护性大大提高，可以在一个位置而不是多个位置进行更改。能够（快速）进行单元测试将大幅减少代码中的错误 - 特别是在长期或社区驱动的（开源）项目中。提前做额外的工作将节省时间并减少以后的麻烦。资源您可以使用 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 代码的详细内容。