だから、最初のヒント。 単体テストについて知っていることはすべて忘れてください。 あなたが彼らなしではできないと言った人にスツールを投げます。 どのケースでそれらを使用する必要があり、どのケースで-非実用的であるかを理解してみましょう。
PHPプログラマーは、間違った終わりから開始するため、テストを書くことはめったにないと確信しています。 誰もがテストが優れていてクールであることを知っています。 しかし、同じPHPUnitの Webサイトを開き、+ b操作の実行方法を知っている計算機のテストに関するカラフルな例を読んで、彼らは自問します：この計算機は私のアプリケーションとどう関係するのでしょうか？ 回答：いいえ。 他のテストフレームワークのサイトにある、同様のすべての例とまったく同じです。 PHPが主にWeb用であることを誰もが忘れているかのように。 MVCパラダイムに基づいたサイトではなく、誰もが電卓を書くかのように。
Webサイトを作成している、またはWebアプリケーションを開発しているとします。 すでにいくつかのページ、フォーム、さらにはインタラクティブな要素が含まれています。 サイトが機能していることをどのように確認しますか（または、たとえば顧客）。 きっとあなたはサイトに行き、リンクをクリックし、フォームに記入し、結果を見てください。 そして、良い方法では、フォームをクリックして記入するこれらのすべての日常的なプロセスを最初に自動化する必要があります。
したがって、機能テスト（または受け入れテスト）について説明します。
機能テストは、機能要件の実現可能性、つまり特定の条件下でユーザーが必要とするタスクを解決するソフトウェアの能力を検証するためのソフトウェアテストです。 機能要件により、ソフトウェアの機能、解決するタスクが決まります。
ウィキペディア
なぜテストを書く価値があるのでしょうか？ はい、あなたのサイトが機能し、すべてがそこで機能していることを確認するだけです。 受け入れテストは、堅実なWebアプリケーションや、ひざの上で一晩リベットで留められた単純なサイトにも同様に適しています。 したがって、それらから始める価値があります。
機能テストには何がありますか？ 私に知られているすべてのうち、これはCodeceptionであり、たとえば、PHPUnit + MinkまたはSeleniumの直接使用です。 このCookieにBehatを含めたかったのですが、その作者は機能テストにBehatを使用しないように頼みました 。
SeleniumまたはPHPUnit + Minkで簡単にテストできる場合は、おそらくそれらを使用します。 したがって、Codeceptionに焦点を当てます。
テストの説明は次のとおりです。
<?php $I = new WebGuy($scenario); $I->wantTo('see my site is working'); $I->amOnPage('/'); $I->see('Welcome, on my site!'); ?>
ほんの数行で、少なくともサイトのメインページが開くことを確認します。 長い仕事の場合、それを壊すことはそれほど難しくありません。
同様に、さらにアクションを説明できます。
<?php $I->click('Feedback'); $I->see('Submit your feedback'); $I->fillField('Body','Your site is great!'); $I->click('Submit'); $I->see('Thanks for your feedback!'); ?>
ここでは、サイトのフィードバックフォームが機能することを既に確認しています。 少なくともユーザーには、彼の意見が考慮されていることが示されています。
ただし、Habré では、すでにCodeceptionについて書いています 。
次に、単体テストを決定してみましょう。
単体テスト、または単体テストは、プログラムのソースコードの個々のモジュールの正確性を確認できるプログラミングプロセスです。
アイデアは、重要な関数やメソッドごとにテストを書くことです。 これにより、コードの次の変更がリグレッションにつながったかどうか、つまり、プログラムのテスト済みの場所でエラーが発生したかどうかをすばやく確認でき、そのようなエラーの検出と排除も容易になります。
ウィキペディア
それらの使用に関する問題は、通常、WebアプリケーションがCMSまたはフレームワークに基づいていることです。 また、特定のモジュールをテスト用に割り当てることが常に可能であるとは限りません。 アプリケーションロジックが異なるクラスに散在していて、特定の各ユニットが本質的に何もしない場合は特に不便です。 テストプロセスは、すべてのモジュールが何らかの形で相互接続され、多くの継承されたメソッド、構成を持っているという事実によってさらに複雑になり、コードがどこにあり、ライブラリコードがどこにあるかを区別するのが非常に難しい場合があります。
しかし、機能テストのフレームワークでユーザーができることをすべてチェックした場合、単体テストではユーザーがしてはいけないことを考慮しようとします。
たとえば、コードで同じ名前の2人のユーザーを作成できるかどうかを確認します。 複製を作成しようとすると、アプリケーションがクラッシュせず、死の白い画面が表示されないことを確認しますが、エラーをインターセプトし、そのテキストをユーザーに表示します。 同意して、ユーザーはあなたが望む以上のことをすることができます。 したがって、考えられるすべてのシナリオを予測して機能テストでカバーすることは不可能な場合があります。
または別の例：あなたのサイトでプロモーションがあります-100人の登録ユーザーごとにギフトを受け取ります。 100人の追加ユーザーを作成せず、ギフトが提供されていることを確認するにはどうすればよいですか？ ここでは、すでに単体テストを記述しています。 それらがなければ、ほとんどの場合、何もありません。
アプリケーションがビジネスロジックを明確に表現している場合、たとえば、「このメソッドはユーザーを作成し、このメソッドを使用するとグループのステータスを変更できます」場合、このようなメソッドを単体テストでカバーすることは非常に合理的です。
そしてもう1つ：フレームワーク、CMS、またはこれらのフレームワークとCMSの一部のモジュールに基づいてWebサイトまたはアプリケーションを作成している場合は、必ずユニットテストを作成してください。 オプションはありません。 サードパーティの一般的なソリューションを使用していて、自転車を発明していない場合、そのコードは作成者によってすでにテストされている可能性が高いため、テストに専念しないでください。
単体テストには、多くのフレームワークがあります。
従来の単体テストの代替として：
繰り返しますが、自分で選択してください。 もちろんPHPUnitが標準ですが、より現代的なフレームワークはよりシンプルで効率的です。
要約すると、私はこれを言うでしょう：テストは本当に必要であり、あなたが思うほど怖くないです。 受け入れテストでテストの作成を開始し、モジュール化を続行します。 重要なものをテストし、確信がないものをテストします 。
免責事項 ：この記事の一連の意図的な単純化と不正確さをおaびします。 私の観点からは、PHPアプリケーションの自動テストの基本原則を説明するために必要です。 アプリケーションをテストする人が多いほど、世界は良くなります。 結局のところ、主なことは開始することです。