単体テスト理論 (続き): パート 2

前回の記事では、WordPress における単体テストの理論について説明し始めました。具体的には、単体テストのテーマとプラグインに関する作業をレビューし、次にコードユニットの議論に移り、それがテストにどのような影響を与えるか、そしてソフトウェア開発のより大きな世界における単体テストをレビューします。

WordPress における単体テストの理論について、問題の特定、アーキテクチャの推進、プロジェクトの文書化などにどのように役立つかという観点から引き続き説明していきます。

---

問題を見つけて時間を節約する

このシリーズの前の内容を思い出してください。単体テストの従来の方法は次のとおりです。

• テストを作成し、実行します (失敗することを承知で)
• このメソッドを通過させる関数を作成します。
• テストを実行します。テストが失敗した場合は関数の作業を続行し、失敗した場合は次の関数に進みます。

はい、最初のステップは少し独断的です。失敗するとわかっていることを実行するのに時間を無駄にする必要はありません。しかし、要点はわかります。しかし、この特定のテクニックを開発に適用し始めると、コードを書くときに特定のリズムが生まれ、それが全体の目標の一部であることがわかります。

しかし、それは半分にすぎません。実際、単体テストは開発の初期段階で問題を発見するのに役立ちます。

これを理解するには、このアイデアを確認するのが最善です。

実際に WordPress ダッシュボードにログインせずにユーザー アカウントを作成できるようにする WordPress ベースのプロジェクトの機能を開発しているとします。これは、登録、必要な検証、およびパスワードと電子メールを生成するためのコードを処理するページ テンプレートを設定していることを前提としています。

あなたはブラウザにページをロードし、同じ電子メール アドレスを持つユーザー、間違ったパスワードを持つユーザー、不正な文字を含むユーザーなどを作成しようとします。お分かりかと思いますが、合格か不合格かを確認する方法は複数あります。これはとてもひどいです！つまり、ユーザー登録機能を変更するたびに、問題が発生しないように同じ n 回の登録を実行する必要があります。

または、これを処理する一連のテストを作成し、コードが変更されるたびに実行することもできます。

そうです、単体テストの作成には多くの時間がかかることがありますが、コードの単位を変更するたびに節約される時間を見てください。これはそれだけの価値があり、誰かがテストの 1 つの順列をモックするのを忘れたために見逃されていた可能性のある問題を早期 (つまり、運用環境にリリースする前) に発見するのに役立ちます。

---

自己録音

単体テストを作成するときは、コードが実際に機能することを確認してコードの品質を向上させるだけでなく、基本的に開発者向けのドキュメントも提供します。

製品に組み込まれた機能の単体テストを行う場合は、その機能がどのように動作するか、いつ失敗するか、いつ成功するかに関するドキュメントを提供します。

これにはいくつかの前提条件が含まれます。具体的には、関数とそれに関連するテストに論理的に名前を付けてグループ化しており、各関数を正しくテストしているということです。

PHPUnit を使用すると、WordPress 単体テストで読みやすいアサーションを簡単に実行できます。プロジェクトを構成する関数で使用可能なassertTrue、assertFalse、またはその他のアサーションを宣言するだけです。

上記の例に従うと、空の電子メール アドレスで登録しようとしたときにユーザー登録関数が確実に失敗するように関数を作成できることを意味します。

リーリー

単純な例かもしれませんが、重要な点は変わりません。コードは自己文書化され、明確な単体テストを記述するだけで済みます。

---

＃＃＃建築＃＃＃

おそらく、単体テストの最も過小評価されている利点の 1 つは、プロジェクトのアーキテクチャの推進に役立つことです。通常、テーマまたはプラグインの開発は、次の 2 つの方法のいずれかで開始できます。

関数をリストし、ユーザー インターフェイスを描画し、コードを記述します

ファイルがどのように連携するかを図にしてコードを記述します
2. これらは本質的に悪いことではありませんが、弱いと思います (私が共有したい以上のことをしていることを最初に認めます!)。しかし、「コードを書く」というステップには多くの責任が伴います。

これは、長い間コーディングをしている人にとっては非常に馴染み深いものであるため、最終的には「ああ...私はそれを考えていませんでした」と気づくでしょう。

運が良ければ、これは通常、無視したケースを処理するヘルパー メソッドまたは別の条件を作成できることを意味しますが、最悪の場合、クラス全体または関数セット全体を再設計しなければならない可能性があることを意味します。この問題を解決するもの。

単体テストは、完璧ではありませんが、この状況を軽減するのに役立ちます。

最初から、テーマまたはプラグインに提供したいすべての機能のリストがあるという事実を考慮してください。コードはまだ何も書いていませんが、何らかの種類の UI スケッチやクラス図のセットはあるかもしれません。

接下来，您开始编写要编写的测试以测试您的项目。回想一下，单元测试的一部分是将代码分解为尽可能的原子单元，因此您的任务是为每个单元编写单元测试，咳咳。

由于单元测试的性质，您本质上会以不同的方式思考您的代码：您正在考虑“编写测试”，而不是“编写代码”，并且因为您必须在更原子的级别上进行思考，您会情不自禁地考虑经常被归入“编写代码”的边缘案例。

---

代码的语言

作为开发人员，我们非常习惯使用不断强化我们编写代码的约定。我的意思是，我们倾向于提供缩写的变量名称、神秘的函数名称和类名称，这些名称对于您自己或项目团队之外的任何人来说可能没有任何意义。

单元测试不一定是编写更易于阅读的代码的关键，但它可以进一步帮助提供更清晰的函数名称。

回想一下您读过的第一本编程书、您参加的第一堂计算机科学课或者您看到的第一段开源代码，方法名称通常是动词。为什么他们不应该这样？方法是封装代码的方法，做一些事情。但随着我们在项目上工作的时间越来越长，我们变得越来越懒，我们的代码从“register_user_and_email_password()”变成“new_account()”。

显然，前者比后者更清晰，但如果我们致力于高质量的单元测试，并且希望确保我们的单元测试易于阅读，为了使它们易于阅读，我们的函数名称必须易于阅读。

这不是更容易阅读吗：

$this->assertFalse( register_user_and_email_password( '' ) );

而不是这个？

$this->assertFalse( new_account( '' ) );

同样，这也许是一个简单的示例，但原则仍然是：编写良好的单元测试，以帮助自我记录驱动函数语言的代码。

---

结论

我们已经讨论了单元测试的基础知识以及主要优点，但是我们还没有讨论单元测试带来的缺点，我们甚至还没有考虑如何将其合并到我们的项目中。工作流程。

因此，在下一篇文章中，我们将尝试做到这一点。

以上が単体テスト理論 (続き): パート 2の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。