これは、出版物の第3部です。 ここから始まりを読むことができます：
ABAPの単体テスト。 パート1 最初のテスト
ABAPの単体テスト。 パート2 すくい
測定されます
テスト品質の主な測定基準はカバレッジであると考えられています。 多くの場合、開発中のインターネットで「フルカバレッジ」スタイルの言語を見つけることができます。 原則として、完全なカバレッジは100.00％の絶対値として理解されます。
カバレッジの割合は疑わしい数字であり、「平均病院温度」とまったく同じです。 プロジェクトのカバレッジの割合は、その部分の平均カバレッジです。 つまり、モジュール1のカバレッジは80％、モジュール2のカバレッジは20％、平均カバレッジは50％になります（モジュールのコンテンツがほぼ等しいと仮定した場合）。 80％が20％の4倍優れているというのは本当ですか？
平均は異なります。 ABAP UNITには、3つの異なるカバレッジメトリックがあります。
- 手順別（手順範囲）
- 指示に従って（ステートメントカバレッジ）
- 支店カバレッジ
たとえば、クラス、関数のグループ、またはルーチンのプールがあります。
form do_something. c = a. d = b. endform. form do_something_else. if a > b. c = a. d = a. else. c = b. d = b. if d > 1000. d = 1000. endif. endif. endform. form do_nothing. if 1 = 2. c = d = 0. endif. endform.
NB。 ルーチンのプールは、関数のグループやメソッドを持つクラスよりも簡単に実証できます。 ルーチンのプールは、クラスよりもはるかに少ない文字数で記述されます。 パラメーターは定義の範囲外です。 この小さなデモンストレーションには大きな違いはありません。 そして一般的に：すべての変数は架空のものであり、生産的なコードとの偶然の一致はランダムです。
そして、サブルーチン、関数、メソッドごとに1つの簡単なテストを書いたとします。 すべてのルーチンで、値[A = 7、B = 77]を使用します。
class lcl_test definition for testing duration short risk level harmless. private section. methods: setup. methods: do_something for testing. methods: do_something_else for testing. methods: do_nothing for testing. endclass. class lcl_test implementation. method setup. a = 7. b = 77. endmethod. method do_something. perform do_something. endmethod. method do_something_else. perform do_something_else. endmethod. method do_nothing. perform do_nothing. endmethod. endclass.
NB：現時点では一般的な初期化を行い、結果の確認を省略します。
手続き範囲
これは最も単純なケースで、指を頼りにすることができます。 手順によるカバレッジは、100％=（1 + 1 + 1）/（1 + 1 + 1）* 100です。
ステートメントカバレッジ
そして、同じ手順で命令の数を数えるとしたら？
各手順には、異なる数の指示が含まれています。 さらに、指定された入力パラメーターでは、すべての命令が呼び出されるわけではありません。
- DO_SOMETHING：3つの指示のうち3つが解決した
- DO_SOMETHING_ELSE：8つの命令のうち5つが機能しました
- DO_NOTHING：3つの命令のうち2つが解決した
命令は単純と見なされます。通常の命令、手順自体は命令と見なされ、条件は命令と見なされます。 ENDIF句の完了構文は、遷移の場所を決定するだけで、計算やアクションに関連付けられていないため、命令としてカウントされません。
指示に従ってメトリックを計算すると、71％=（3 + 5 + 2）/（3 + 8 + 3）* 100になります。
DO_SOMETHING_ELSEのメトリックの作業を検討してください。 ABAP開発ツールは、メトリックに従ってソース行を色付けできます。
視覚的、迅速、明確に。 驚くべきことに、ABAPにはこれさえ期待していませんでした。
このカラーリングから、他の初期パラメーターを取得した場合、カバレッジの割合が異なる可能性があることが明らかになります。 [A = 77、B = 7]の場合：
同時に、このメトリックによる完全なカバレッジは、複数のテストシナリオを使用してのみ達成できることが明らかになります。 たとえば、2つのテスト[A = 77、B = 7]および[A = 7、B = 7777]では、すべてが緑色になります。
したがって、メトリックは100％になります。 しばらく落ち着くことができます。
支店カバレッジ
このメトリックは少し難しくなります。 彼女は、分岐を引き起こす可能性のあるすべての命令を受け取り、そのような各命令が双方向で実行されることを確認します。
最後の例のベースを見てみましょう：
2つのテストの最初の命令[IF A> B]は2回機能しました。1回はTRUE [A = 77、B = 7]、1回はFALSE [A = 7、B = 7777]です。
しかし、2番目の命令[IF D> 1000]は、TRUE [A = 7、B = 7777]で1回しか機能しませんでした。
関数呼び出し自体は無条件ユニットと見なされ、さらに最初のIFは2つのうち2つを与え、2番目のIFは2つのうち1つだけを与えます。 したがって、メトリックは80％=（1 + 2 + 1）/（1 + 2 + 2）* 100になります。
そしてここで、1つの機能に対して2つのテストでは十分ではないことが判明しましたが、3つのテストが必要です。 2番目のIFがFALSEで動作するように、スクリプト[A = 7、B = 77]を前の2つに追加できます。
3番目のシナリオを追加すると、この関数のメトリックは100％になりました。
DO_NOTHINGについてはどうですか？ 分岐または命令のメトリックが100％になるようなテストはありません。 明らかに、関数はリファクタリングを必要とし、それなしでは完全なカバレッジに到達することは不可能です。 この関数は削除するか、DO_NOTHINGからDO_SOMETHING_COMPLETELY_DIFFERENTに変更する必要があります。
百パーセント！
さらに多くのテストを記述できず、100％を超えることはできません。
プロシージャカバレッジメトリックの詳細度が低いことは明らかです。 多くのコードがあり、まだテストがほとんどない場合は、初期段階でのみ注意深く見ることができます。 しかし、残りの2つのメトリックのうち、どのメトリックを注意深く見る必要がありますか？ 最初のメトリックが機能のカバー率を示す場合、最後のメトリックは機能のカバー率を示します。
お気づきのように、指示に従って100％を取得できますが、ブランチには100％はありません。 しかし、その逆ではありません（または、そのような例は思いつきません）。 すでにブランチで100％を獲得している場合は、すべての隅に行き、すべての指示を増やしました。 しかし、ブランチメトリックスは、明示的な重み付けインジケーターの1つ（コードの行数、つまり命令数）を無視するため、平均して指標の重み係数をあまり示していないように見えるかもしれません。
ところで：はい、空の手順で100％のパフォーマンスが得られます。
同意は同意です
ABAPユニットの操作では、次のことは重要ではありません。
- 一般にいくつのテストクラスがありますか。
- テストクラスの名前は何ですか？
- それはどの場所にありますか？
- 彼のメソッドは何と呼ばれています。
主なことは、ローカルクラス：
- 利用可能でした。
- 「テスト用」という愛称。
- 「テスト用」と呼ばれるメソッドがありました。
しかし、一方で、変数名でさえランダムな文字のセットではありません。
したがって、各アイテムには、画像の一般的な認識を促進する一般的な条件付き配置が必要です。 命名規則またはフォーマット規則のように。
なに？
テストクラスは、必要なだけ正確に設定する必要があります。 少なくとも、各ラージオブジェクト（関数のグループ、プログラム、クラス）には、可能な限り1つのテストクラスが必要です。
複数の関連する関数の単純なグループがある場合、1つのクラスで十分です。 しかし、グループに疎結合関数のパックが6つある場合、ここで「関数グループはいくつあるべきですか？」という質問をここで取り上げる必要があります。これはまったく異なる会話のトピックです。
この質問に正解した後、分割可能性の基準としてSETUPメソッドを使用できます。 このようなメソッドはクラス内に1つだけ存在する必要があり、各テストメソッドの前に自動的に呼び出されます。
各スクリプトは個別のテストメソッドを提供する必要があり、メソッドの名前はテストされたコードから直接派生する必要があります。
どこ？
単体テストの原則の1つ：テストクラスは、管轄区域にあるコードのみをテストする必要があります。 テストはソースコード内のどこにでも配置できますが、動作する機能をテストから分離することは価値があります。
ここで、機能グループのウィザードは、事前定義されたテンプレートに従って個別のインクルードプログラムを作成します。たとえば、機能グループZFI_BTEのLZFI_BTET99です。 私はそれについて何も間違っているとは思わない。私はそれをモデルとしてとらえ、同じやり方で続けなければならない。
また、REPORTのようなプログラムでは、テンプレートに応じた名前で、厳密に1つの個別のincludeプログラムにテストを記述します。
ただし、コード、テスト、コード、テストなど、あらゆるものを混同して書くことを禁止することはできません...
いつ？
5分ごとに単体テストのフルサイクルを実行することはできません。 ただし、少なくとも、リクエストをリリースする前に、関連するオブジェクトのテストを実行する必要があります。
まとめると
要約するだけの要約：
- あなたはそれと共に生きることができます。
- テストコードはより生産的なコードです。
- 多くの場合、TDDアプローチは正当化され、推奨されます。
- テストを行わずに既存の生産的なコードをレビューすると、脳回に大きな負担がかかります。
- すでに記述されたコードをテストでカバーしようとすると、多くの場合、リファクタリングなしで実行できます。 また、リファクタリングは、テストカバレッジ自体とは若干異なり、より難しいタスクです。 リファクタリングは、コードで何か他のことをするまで延期できます。
- 長年にわたって変更されていない生産的なコードがある場合は、最後のターンにテストでカバーする必要があります。
- ループが閉じているため、コードがカバーされないままになる可能性があります。最初に深刻なリファクタリングを行う必要があるため、適切なテストを実行できません。テストがなくなるまでリファクタリングは推奨されません。
- 場合によっては、テストカバレッジを実行できないことがあります。 それは起こります。 謙虚に。
- カバレッジの完全性を計算するための一部のメトリックについては、他のメトリックよりも100％を達成する方がはるかに簡単です。 これは、あなたがそれほど簡単にする必要があるという意味ではありません。
- 私はシステムの標準コードのテストに気づかず、もしそうなら、それらは実行することを禁じられるでしょう。
h騒の中で、主なものを忘れないでください。テストはそれ自体で終わりではありません。 すべてが有益であるべきです。
テストの直接の本当の利点は、誰かがこの機能を終了したときに、時間が経つにつれてテストが失敗するときだけです。
負傷を防ぐには、正しく落ちる能力が最善の方法だからです。 これが空手家やサイクリストに当てはまる場合、プログラマーにも役立ちます。 ペダリング中にひどく落ちるよりも、ペダリング中にひどく落ちる方が良いです。 正しく落下する能力は、適切な機器よりも重要です。
そして今、あなたは間接的な利益のみを得ることができます：
- ドキュメントの使用シナリオをテストします
- テストは注意が必要な場所の特定に役立ちます（リファクタリング）
- テストは、手動でテストするのが難しい場所で基本的なチェックを実行するのに役立ちます。
再び会うまで、今日はこれで終わりです。