単体テストを実行するために PHPUnit フレームワークをインストールしました。テスト ケースを作成し、既存の PHPUnit ライブラリをテスト用に使用しました。
ステージングおよび本番環境で PHPUnit フレームワークを構成する必要がありますか? その場合、phpunit テスト フレームワークと関連ファイルは、ステージングと本番環境で不要なメモリを消費します。
ローカル環境で PHPUnit テスト フレームワークを使用するだけで十分ですか?
単体テストを独自の最上位サブディレクトリに保持する場合 (例: How do you manage the unit test files in projects? do you add them in git? をtests
参照) 、git チェックアウト後にディレクトリを単純に削除できます。または、ftp を使用している場合は、そのディレクトリ以外のすべてのディレクトリを ftp します。または、rsync を使用している場合は、--exclude=tests/
.
しかし、私はこれまでに回答した他の人々とは意見が一致していません。安心のために、ステージング サーバーと運用サーバーで単体テストを実行すると非常に便利です。開発サーバーでテストに合格しても、ステージングまたは本番環境で失敗した場合は、重大な危険信号があります。単体テストで、ライブ サーバーへの依存関係の 1 つが別のバージョンであることを伝える方が、顧客にそれを発見してもらうよりも優れています。
ただし、これには注意が必要です。単体テストのいずれかが自己完結型でない場合、それらを実行してはなりません。明らかなケースは、彼らがデータベースを使用している場合であり、単体テストはそのデータベースを作成することから始めず (実動 DB と衝突することのない名前で)、それを削除して終了します。もう 1 つのケースは、直接的または間接的にディスク ファイルを更新するテストです。特に、ロギングを行う関数について考えてください。注意が必要なもう 1 つのタイプのテストは、終了までに時間がかかるものや、大量の CPU やメモリを使用するものです。実動サーバーが稼動していて負荷がかかっているときは、これらが決して実行されないようにしてください。
そのコピーを作成する 1 つのアイデアphpunit.xml.dist
は、安全で副作用のないテストを明示的にリストします。次に、で実行しphpunit --configuration production_tests.xml
ます。または、テスト内で、 を使用@group
して、安全または安全でないテスト関数にフラグを立ててから、phpunit --group safe_for_production
またはphpunit --exclude-group modifies_db
理想的なシナリオは、開発、ステージング、本番の 3 つのレベルがあるところだと思います。
開発はphpunitとデバッガーを保持する場所ですが、このマシンは本番とはまったく異なる場合があります。ここでは、ubuntu にデプロイする場合でも、たとえば Windows で開発できます。
ステージング マシンは phpunit とデバッガーを保持することもできますが、サーバーと同一でない場合は非常に近いアーキテクチャを持ち、実際のデータベースのコピーにアクセスする必要があります。運用サーバーと同じバージョンの apache/php/mysql/libraries である Linux のフレーバーが必要です。実際のデータにアクセスできることも、場合によっては違いを生むことがあります。
実稼働マシンには、phpunit またはデバッガー ツールを含めないでください。それは、開発者としてのあなたの管理下にさえあるべきではありません。おそらく、主任開発者とシステム管理者がそこにコードを展開し、必要に応じてアプリを微調整し、ロールバックやその他の不測の事態に備えています。
いいえ。GordonMが述べたように、そうすることはセキュリティにとって悪いことです。また、実稼働環境に配置する前にテストする必要があるので、なぜそうしたいのでしょうか。一部のデバッグツール(特にPHPUnitではありませんが、その他のツール)も、アプリケーションの効率を低下させます。