PHPUnitポケットガイド-第三章PHPUnitの目的
第三章PHPUnitの目的
ここまでArrayと組み込み関数sizeof()のテストは2つしかありません.大量のarray_*のテストを開始すると()関数の場合、それぞれにテストが必要です.私たちはすべて最初から書くことができます.しかし、より良い方法は、一度にテストの基礎フレームワークを書き、後でテストごとに異なる部分だけを書くことです.PHPUnitはこのようなインフラストラクチャです.
例5は、例4の2つのテストをPHPUnitで書き換える方法を示している.
例5.PHPUnitでArrayとsizeof()をテストする.
例5 PHPUnitでテストを書くための基本的な手順を示します.
1.クラスClassのテストクラスはClassTestです.
2.ClassTest一般継承PHPUnit 2_Framework_TestCase.
3.テストは公有の方法で、パラメータがなく、名前はtest*です.
4.試験方法において、assertEquals()のような断言関数(表6参照)は、実際の値が所望の値に一致するか否かを断言するために使用される.
PHPUnitのようなフレームワークは、競合しているように見える問題を解決する必要があります.テストは、次の条件を同時に満たす必要があります.
学びやすい
テストは簡単に学ばなければなりません.そうしないと、開発者は勉強しません.
開発しやすい
テストは容易に開発しなければならない.そうしないと、開発者は開発しない.
読みやすい
テストコードには外部関係がない必要があります.これにより、テスト自体が混乱しないようにします.
実行しやすい
テストは簡単に実行できるはずで、実行した結果は明確で明確な形式で表現されています.
高速実行
テストは、毎日千回以上実行できるように、迅速に実行する必要があります.
コード分離
テスト間で相互に影響を与えることはできません.テスト順序の変更は結果に影響を与えるべきではありません.
コンビネーション可能
コード分離の必然的な結果である任意の組合せでテストを実行できるはずです.
これらの制約には2つの主要な競合があります.
学びやすいvs開発しやすい
テストは通常、プログラミングのすべての柔軟性に適用する必要はありません.多くのテストツールは、テストに必要な特性の最小セットを書くだけの独自のテストスクリプト言語を提供しています.ノイズがあなたのテスト内容を妨害しないため、書かれたテストは読みやすく、書きやすいです.しかし、新しい編み物や道具を学ぶのは不便で、聞き取りを混乱させやすい.
コード分離vs高速実行
1つのテストの結果が他のテストに影響を与えないようにするには、各テストが実行を開始する段階で、テストの全テーマを作成し、戻ってから実行前の状態を回復する必要があります.しかし、状態を設定するのに時間がかかる(例えば、データベースに接続し、実際のデータで既知の状態に初期化する)
PHPUnitがこの問題を解決する方法はPHPをテスト言語として採用することである.時には、フル機能のPHPは書くのが短くて、直接のテストは強すぎることがありますが、私たちが利用しているプログラマーはPHPを使うすべての経験を持っています.無理なテスト担当者を説得する必要があるため、これらの初期テストを書く敷居を下げることが重要です.
--------------------------------------------------------------------------------------------------------------------
原文:
Chapter 3. PHPUnit's Goals
So far, we only have two tests for the Array built-in and the sizeof( ) function. When we start to test the numerous array_*( ) functions PHP offers, we will need to write a test for each of them. We could write all these tests from scratch. However, it is much better to write a testing infrastructure once and then write only the unique parts of each test. PHPUnit is such an infrastructure.
Example 5 shows how we have to rewrite our two tests from Example 4 so that we can use them with PHPUnit.
Example 5. Testing Array and sizeof( ) with PHPUnit
require_once 'PHPUnit2/Framework/TestCase.php';
class ArrayTest extends PHPUnit2_Framework_TestCase {
public function testNewArrayIsEmpty( ) {
//Create the Array fixture.
$fixture = Array( );
//Assert that the size of the Array fixture is 0.
$this->assertEquals(0, sizeof($fixture));
}
public function testArrayContainsAnElement( ) {
//Create the Array fixture.
$fixture = Array( );
//Add an element to the Array fixture.
$fixture[] = 'Element';
//Assert that the size of the Array fixture is 1.
$this->assertEquals(1, sizeof($fixture));
}
}
?>
Example 5 shows the basic steps for writing tests with PHPUnit:
The tests for a class Class go into a class ClassTest.
ClassTest inherits (most of the time) from PHPUnit2_ Framework_TestCase.
The tests are public methods that expect no parameters and are named test*.
Inside the test methods, assertion methods such as assertEquals( ) (see Table 6) are used to assert that an actual value matches an expected value.
A framework such as PHPUnit has to resolve a set of constraints, some of which seem to conflict with each other. Simultaneously, tests should be:
Easy to learn to write.
Tests should be easy to learn to write; otherwise, developers will not learn to write them.
Easy to write.
Tests should be easy to write; otherwise, developers will not write them.
Easy to read.
Test code should contain no extraneous overhead so that the test itself does not get lost in the noise that surrounds it.
Easy to execute.
Tests should run at the touch of a button and present their results in a clear and unambiguous format.
Quick to execute.
Tests should run fast so they can be run hundreds or thousands of times a day.
Isolated.
Tests should not affect each other. If the order in which the tests are run changes, the results of the tests should not change.
Composable.
We should be able to run any number or combination of tests together. This is a corollary of isolation.
There are two main clashes within this group of constraints:
Easy to learn to write versus easy to write.
Tests do not generally require all the flexibility of a programming language. Many testing tools provide their own scripting language that includes only the minimum necessary features for writing tests. The resulting tests are easy to read and write because they have no noise to distract you from the content of the tests. However, learning yet another programming language and set of programming tools is inconvenient and clutters the mind.
Isolated versus quick to execute.
If you want the results of one test not to affect the results of another test, each test should create the full state of the testing before it begins to execute, and return the world to its original state when it finishes. However, setting it up can take a long time (e.g., connecting to a database and initializing it to a known state using realistic data).
PHPUnit attempts to resolve these conflicts by using PHP as the testing language. Sometimes the full power of PHP is overkill for writing short, straight-line tests, but by using PHP, we leverage all the experience and tools programmers already have in place. Because we are trying to convince reluctant testers, lowering the barrier to writing those initial tests is particularly important.
PHPUnit errs on the side of isolation over quick execution. Isolated tests are valuable because they provide high-quality feedback. You do not get a report with a bunch of test failures that were really caused because one test at the beginning of the suite failed and left the world messed up for the rest of the tests. This orientation toward isolated tests encourages designs with a large number of simple objects. Each object can be tested quickly in isolation. The result is better designs and faster tests.
PHPUnit assumes that most tests succeed, and it is not worth reporting the details of successful tests. When a test fails, that fact is worth noting and reporting. The vast majority of tests should succeed and are not worth commenting on, except to count the number of tests that run. This is an assumption that is really built into the reporting classes and not into the core of PHPUnit. When the results of a test run are reported, you see how many tests were executed, but you only see details for those that failed.
Tests are expected to be fine-grained, testing one aspect of one object. Hence, the first time a test fails, execution of the test halts, and PHPUnit reports the failure. It is an art to test by running many small tests. Fine-grained tests improve the overall design of the system.
When you test an object with PHPUnit, you do so only through the object's public interface. Testing based only on publicly visible behavior encourages you to confront and solve difficult design problems before the results of poor design can affect large parts of the system.
ここまでArrayと組み込み関数sizeof()のテストは2つしかありません.大量のarray_*のテストを開始すると()関数の場合、それぞれにテストが必要です.私たちはすべて最初から書くことができます.しかし、より良い方法は、一度にテストの基礎フレームワークを書き、後でテストごとに異なる部分だけを書くことです.PHPUnitはこのようなインフラストラクチャです.
例5は、例4の2つのテストをPHPUnitで書き換える方法を示している.
例5.PHPUnitでArrayとsizeof()をテストする.
<?phprequire_once 'PHPUnit2/Framework/TestCase.php';class ArrayTest extends PHPUnit2_Framework_TestCase { public function testNewArrayIsEmpty( ) { // fixture。 $fixture = Array( ); // fixture 0。 $this->assertEquals(0, sizeof($fixture)); } public function testArrayContainsAnElement( ) { // fixture。 $fixture = Array( ); // fixture 。 $fixture[] = 'Element'; // fixture 1。 $this->assertEquals(1, sizeof($fixture)); }}?>例5 PHPUnitでテストを書くための基本的な手順を示します.
1.クラスClassのテストクラスはClassTestです.
2.ClassTest一般継承PHPUnit 2_Framework_TestCase.
3.テストは公有の方法で、パラメータがなく、名前はtest*です.
4.試験方法において、assertEquals()のような断言関数(表6参照)は、実際の値が所望の値に一致するか否かを断言するために使用される.
PHPUnitのようなフレームワークは、競合しているように見える問題を解決する必要があります.テストは、次の条件を同時に満たす必要があります.
学びやすい
テストは簡単に学ばなければなりません.そうしないと、開発者は勉強しません.
開発しやすい
テストは容易に開発しなければならない.そうしないと、開発者は開発しない.
読みやすい
テストコードには外部関係がない必要があります.これにより、テスト自体が混乱しないようにします.
実行しやすい
テストは簡単に実行できるはずで、実行した結果は明確で明確な形式で表現されています.
高速実行
テストは、毎日千回以上実行できるように、迅速に実行する必要があります.
コード分離
テスト間で相互に影響を与えることはできません.テスト順序の変更は結果に影響を与えるべきではありません.
コンビネーション可能
コード分離の必然的な結果である任意の組合せでテストを実行できるはずです.
これらの制約には2つの主要な競合があります.
学びやすいvs開発しやすい
テストは通常、プログラミングのすべての柔軟性に適用する必要はありません.多くのテストツールは、テストに必要な特性の最小セットを書くだけの独自のテストスクリプト言語を提供しています.ノイズがあなたのテスト内容を妨害しないため、書かれたテストは読みやすく、書きやすいです.しかし、新しい編み物や道具を学ぶのは不便で、聞き取りを混乱させやすい.
コード分離vs高速実行
1つのテストの結果が他のテストに影響を与えないようにするには、各テストが実行を開始する段階で、テストの全テーマを作成し、戻ってから実行前の状態を回復する必要があります.しかし、状態を設定するのに時間がかかる(例えば、データベースに接続し、実際のデータで既知の状態に初期化する)
PHPUnitがこの問題を解決する方法はPHPをテスト言語として採用することである.時には、フル機能のPHPは書くのが短くて、直接のテストは強すぎることがありますが、私たちが利用しているプログラマーはPHPを使うすべての経験を持っています.無理なテスト担当者を説得する必要があるため、これらの初期テストを書く敷居を下げることが重要です.
--------------------------------------------------------------------------------------------------------------------
原文:
Chapter 3. PHPUnit's Goals
So far, we only have two tests for the Array built-in and the sizeof( ) function. When we start to test the numerous array_*( ) functions PHP offers, we will need to write a test for each of them. We could write all these tests from scratch. However, it is much better to write a testing infrastructure once and then write only the unique parts of each test. PHPUnit is such an infrastructure.
Example 5 shows how we have to rewrite our two tests from Example 4 so that we can use them with PHPUnit.
Example 5. Testing Array and sizeof( ) with PHPUnit
require_once 'PHPUnit2/Framework/TestCase.php';
class ArrayTest extends PHPUnit2_Framework_TestCase {
public function testNewArrayIsEmpty( ) {
//Create the Array fixture.
$fixture = Array( );
//Assert that the size of the Array fixture is 0.
$this->assertEquals(0, sizeof($fixture));
}
public function testArrayContainsAnElement( ) {
//Create the Array fixture.
$fixture = Array( );
//Add an element to the Array fixture.
$fixture[] = 'Element';
//Assert that the size of the Array fixture is 1.
$this->assertEquals(1, sizeof($fixture));
}
}
?>
Example 5 shows the basic steps for writing tests with PHPUnit:
The tests for a class Class go into a class ClassTest.
ClassTest inherits (most of the time) from PHPUnit2_ Framework_TestCase.
The tests are public methods that expect no parameters and are named test*.
Inside the test methods, assertion methods such as assertEquals( ) (see Table 6) are used to assert that an actual value matches an expected value.
A framework such as PHPUnit has to resolve a set of constraints, some of which seem to conflict with each other. Simultaneously, tests should be:
Easy to learn to write.
Tests should be easy to learn to write; otherwise, developers will not learn to write them.
Easy to write.
Tests should be easy to write; otherwise, developers will not write them.
Easy to read.
Test code should contain no extraneous overhead so that the test itself does not get lost in the noise that surrounds it.
Easy to execute.
Tests should run at the touch of a button and present their results in a clear and unambiguous format.
Quick to execute.
Tests should run fast so they can be run hundreds or thousands of times a day.
Isolated.
Tests should not affect each other. If the order in which the tests are run changes, the results of the tests should not change.
Composable.
We should be able to run any number or combination of tests together. This is a corollary of isolation.
There are two main clashes within this group of constraints:
Easy to learn to write versus easy to write.
Tests do not generally require all the flexibility of a programming language. Many testing tools provide their own scripting language that includes only the minimum necessary features for writing tests. The resulting tests are easy to read and write because they have no noise to distract you from the content of the tests. However, learning yet another programming language and set of programming tools is inconvenient and clutters the mind.
Isolated versus quick to execute.
If you want the results of one test not to affect the results of another test, each test should create the full state of the testing before it begins to execute, and return the world to its original state when it finishes. However, setting it up can take a long time (e.g., connecting to a database and initializing it to a known state using realistic data).
PHPUnit attempts to resolve these conflicts by using PHP as the testing language. Sometimes the full power of PHP is overkill for writing short, straight-line tests, but by using PHP, we leverage all the experience and tools programmers already have in place. Because we are trying to convince reluctant testers, lowering the barrier to writing those initial tests is particularly important.
PHPUnit errs on the side of isolation over quick execution. Isolated tests are valuable because they provide high-quality feedback. You do not get a report with a bunch of test failures that were really caused because one test at the beginning of the suite failed and left the world messed up for the rest of the tests. This orientation toward isolated tests encourages designs with a large number of simple objects. Each object can be tested quickly in isolation. The result is better designs and faster tests.
PHPUnit assumes that most tests succeed, and it is not worth reporting the details of successful tests. When a test fails, that fact is worth noting and reporting. The vast majority of tests should succeed and are not worth commenting on, except to count the number of tests that run. This is an assumption that is really built into the reporting classes and not into the core of PHPUnit. When the results of a test run are reported, you see how many tests were executed, but you only see details for those that failed.
Tests are expected to be fine-grained, testing one aspect of one object. Hence, the first time a test fails, execution of the test halts, and PHPUnit reports the failure. It is an art to test by running many small tests. Fine-grained tests improve the overall design of the system.
When you test an object with PHPUnit, you do so only through the object's public interface. Testing based only on publicly visible behavior encourages you to confront and solve difficult design problems before the results of poor design can affect large parts of the system.