開発の観点からは、まず特定の名前と形式に従って変数と関数を整理します。次に、業界ではテスト駆動の開発を推奨しています。次に、単体テストについて説明します。
TDD は、Test-Driven Development の英語の略語で、アジャイル開発の中核となる実践および技術であり、設計方法論です。 TDD の原則は、機能コードを開発する前に単体テスト ケースのコードを作成することです。
1. TDD の 3 つの法則
法則 1 合格できない単体テストを作成する前に製品コードを作成しないでください。
法則 2: 合格しないだけの単体テストのみを作成できます。コンパイルの失敗は失敗としてカウントされません。
法則 3: 現在失敗しているテストに合格するのに十分な実稼働コードのみを作成してください。
テストは本番コードと並行して記述され、テストは本番コードのわずか数秒前に記述されます。
2. テストを整頓しておく
テストコードは本番コードと同じくらい重要であり、十分に整頓しておく必要があります。
良いものにはすべてテストが伴います。
きれいな単体テスト コードは、コードに多くのメリットをもたらします。テストが汚いほど、最終的にコードも汚くなります。テストが欠けていると、コードは腐り始めます。
3. クリーン テスト
クリーン テストには、可読性という非常に重要な要素があります。
テストコードは明確で、クリーンで、十分に表現力豊かである必要があります。テストでは、できるだけ少ない単語で多くのことを言いましょう。
テストモード:構築-運用-検査、
最初のリンクはテストデータを構築します
2番目のリンクはテストデータを操作します
3番目のリンクは操作が期待した結果が得られるかどうかを検証します。
3.1 特定のフィールドのテスト言語
テスト言語のテストを使用して、読みやすくします。
3.2 二重標準
テスト API のコードには、製品コードとは異なるエンジニアリング標準があり、シンプル、簡潔、表現力豊かである必要がありますが、製品コードと同じくらい効果的である必要があります。
4. テストごとに 1 つのアサーション
各テスト関数にはアサーション ステートメントが 1 つだけあるべきだと考える人もいます。
それぞれ 1 つのコンセプトをテストします。
より良いルールは、1 つの概念のみをテストし、各テスト関数で 1 つのことを実行することです。
5. F.I.R.S.T 原則
クリーンなコードは次のルールに従う必要があります:
高速テストは十分に高速である必要があります。テストは迅速に実行される必要があります。
独立したテストは互いに独立している必要があります。 1 つのテストで次のテストの条件を設定してはなりません。
反復可能なテストは、どのような環境でも繰り返し合格する必要があります。
自己検証テストにはブール出力が必要です。失敗するか合格するかは、ログをチェックしてテストが合格したかどうかを確認するのではなく、直接結論を導き出す必要があります。
タイムリーなテストはタイムリーに作成する必要があります。単体テストは、それを合格させる製品コードの直前に作成する必要があります。
6. 概要
テストはコードと同じくらい重要であり、本番コードのスケーラビリティ、保守性、再利用性を確保し、強化します。テストはクリーンで表現力豊か、そして短くしてください。独自のテストを作成するのに役立つ、ドメイン固有言語のテスト API として発明されました。
実際の開発では、さまざまな外部および内部の要因、タイトな構築スケジュール、短期間、重いタスク、その他多くの要因により、多くのチームは TDD や単体テストを実施していません。この原則に従って、ゆっくりと単体テストの目標に近づいてください...
あなたも好きかもしれません: