テストしやすいアプリケーションの設計。

高品質のソフトウェアを作成するには、定性的にテストすることが非常に重要です。 しかし、プロジェクトがテストを容易にする特別なツールを提供していない場合、テストは非常に困難な作業になる可能性があります。 この記事でそれらについて詳しくお話ししたいと思います。





単体テスト



ユニットテストを使用すると、開発のすべての段階でソフトウェアの品質を制御できます。開発の初期段階で多くのエラーを回避できますが、外部からコードをテストすることはまだ不可能です。

プロジェクトで単体テストを使用する場合は、設計段階でこれをどのように行うかを考える必要があります。 まず、アプリケーションコアを開発し、そのパフォーマンスをテストするエンドツーエンドのテストを作成する必要があります。



カーネルの準備ができていると最初のテストが獲得したときに新しいコンポーネントを追加することができます。 まず、新しいコードがどのように機能するか、入力データと出力データがどうなるかを決定します。 次に、新しいコンポーネントの受け入れテストを作成します。 受け入れテストは、コンポーネント全体の正常性を検証します。 最初は、機能せず、コンパイルさえできません。 すべてのテストが機能するまで、必要な機能を実装するために段階的に開始します。



各開発ステップで、機能を実装する前に単体テストを作成します。 コードに何らかの変更を加えた後、一部のテストが機能しなくなった場合は、テストを修正するまで次の変更に進まないでください。



統合テストでテスト互いに反応成分。

コードを単体テストでテストするのが難しい場合、依存関係が多すぎて便利なインターフェイスがないことを意味します。 このようなコードは、将来的に従うことは難しいだろう、あなたはリファクタリングする必要があります。



ユニットテストスキーム








単体テストには多くの利点があります。 コードの品質がはるかに向上することに気付くでしょう。 タスクは適切に分解され、コンポーネントは強く相互接続されません。 コードの保守と拡張が簡単になります。 エラーを見つけるために何時間もコードをデバッグする必要はありません-単体テストはすぐに正しい場所を指し示します。 コードに変更を加えた後にユニットテストを実行することにより、何も壊していないことを常に確認できます。 ユニットテストは、チームにテスターがいない場合に特に役立ちます。



テスト自動化のためのインターフェース



特に異なる入力データのセットに対して同じアクションを実行する必要がある場合、プログラムの手動テストはかなり時間がかかるプロセスです。 このアプローチでは、何かを見逃したり気付かないことは難しくありません。回帰を見つけることは特に困難です。 ここでは、自動化されたテストが役立ちます。 テストを自動化する多くのフレームワークがあります。 しかし、それらは、主にGUIのテストにのみ適しています。 これらを使用して基本機能をテストする場合、データ処理アルゴリズムは非常に高価で不便です。これは、GUIの変更がすべてのテストの変更を引き付け、そのようなテストの記述が非常に難しいためです。 そのような場合、機能のテストをGUIから分離する必要があります。 これは、コンソールコマンドまたはコマンドライン引数を使用して実行できます。



小さなプロジェクトがある場合、プログラムはデータに対して1つ以上のアクションを実行します。コマンドラインに制限するだけで十分である可能性があります。 入力時に、プログラムは入力データを含むファイルを受信し、実行結果を出力ストリーム、たとえばファイルに出力します。 さまざまな機能を持つ大規模なプロジェクトでは、コンソールコマンドのパーサを追加することができます。 各コマンドは、個々のコンポーネントまたは動作をテストするように設計されます。 テスターは、さまざまな入力データのセットを持つスクリプトを使用してプログラムを実行し、結果を目的のデータと比較することで、テストを簡単に自動化できます。



コンソールをさらに詳しく見てみましょう。



新しいコンポーネントの開発を開始しています。 事前にテスターとテスト方法を話し合ってください。 これが新しいボタンであり、データに対して実行するアクションをクリックするとします。 アクションの正確さをテストし、ボタンが機能するかどうかを確認する必要があります。 これら2つのテストを混在させる必要はありません。 機能をテストするには、新しいコンソールコマンドを追加します。ボタンをクリックすると実行されるアクションを複製する必要があります。 ボタンをテストするには、GUIテストを作成します。



チームの外観、および入力データと出力データの形式についてテスターに​​同意します。 グラフィカルインターフェイスとコンソールコマンドを使用して取得したデータは、テスト対象のコンポーネントの入力に入力される単一の形式にする必要があります。 次に、結果は、画面に表示するグラフィックビューまたはストリームに表示するテキストに変換されます。



テストインターフェイス








したがって、GUIには少数の複雑なテストが必要になり、多数の単純なテキストテストで機能テストを提供できます。 GUIを変更する場合、機能テストを変更する必要はありません。



アサーション



アサーションは、デバッグモードでエラーに関する値を返すチェックです。 入力データと戻り値を検証するためのアサーションを使用してください。 通常、アサーションは実行されません。 アサーションを追加する必要がある最も一般的なケースは、インデックスの正確性のチェック、NULLまたは空の値、スイッチの予期しない値のチェックです。



ダンプとログ



ダンプを作成して、データ構造とログの中間状態をチェックし、プログラムの正しい進行を制御します。 これにより、エラーが発生した段階を迅速に判断できます。 テスト対象のモジュールのログまたはダンプを含むスタートアップモードを提供します。たとえば、コンソールコマンドでもかまいません。



すべてのポイントについてテスターと話し合う



最も重要なことは、あなたが行うすべてのことをテスターと話し合うことです。 あいまいさが生じないように、プログラムがどのように機能するかを一緒に決定します。 コードを書き始める前に、アプリケーションをどのようにテストするかを考えてください。 テストツールをアーキテクチャに組み込む必要があります。 どのツールを実装する必要があるか話し合ってください。 これを怠るな、テスターの仕事はより効果的になり、製品はより良くなるだろう。



成功した開発。



All Articles