15

私はそれを認めることを恥じていますが、コードの自動テストを行ったことがありません。通常、関数またはメソッドを作成してから、手動テストを実行して続行します。これは非常に悪い習慣だと気付いたので、自分のやり方を変えようとしています。問題は、実際に始める方法に少し迷っているということです。私はデータベースに接続されたFlaskを使用して小さなPythonWebアプリケーションを作成しています。これを、より良い開発手法に自分自身を強制する機会として使用したいと思います。

データベースにいくつかのテストデータを入力する必要があると思います(おそらく、それを生成するためのスクリプトを作成するだけです)。次に、プログラムの各関数のテストの作成に進みます。

例:システムからすべてのユーザーコメントを取得する関数があります。特定のユーザーのテストを作成してから、返されたコメントIDのリストが手動のデータベースクエリから作成した配列と一致することを確認する必要がありますか?このユニットテストですか?

すべてを理解するのに苦労しているだけです。いくつかの初心者向けのドキュメントに私を向けても、非常にありがたいです。

4

2 に答える 2

22

そこで、まず、自動テストの目的についてお話したいと思います。目的はバグを見つけることではなく、リグレッションをキャッチすることです。バグをキャッチするという利点もありますが、一般に、自動化されたテストスイートを作成して維持するのはかなりの作業です。バグを探しに出かけたばかりの場合は、手動でテストする方がはるかに安価です。自動テストを使用する利点は、大幅な変更を加えたときにスイートを実行でき、世界を壊していないことを確信できることです。この回帰テストは、自動テストを作成する価値がある理由の鍵です。

テストの方法と、一般的なテスト戦略について説明します。私もすべてを説明するつもりです、あなたが私が言うことの半分をすでに知っているならば、怒らないでください。

そうは言っても、テストには大きく分けて3つのレベルがあります。

ユニットテスト

ユニットテストは、最小規模でのテストです。個々の関数やクラスをテストします。あらゆる種類の異なる言語の単体テストに使用できるライブラリがたくさんあります。Pythonの1つの例は、PyUnitです。

あなたは通常、たくさんの小さなスコープのテストを書くことによってユニットテストを達成します。たとえば、独自のコンテナクラスを作成した場合(Pythonではあり得ないが、これは単純な例です)、アイテムの追加、アイテムの削除、アイテムの検索などの単体テストがあります。

コンポーネントテスト

コンポーネントテストとは、プログラムを個々のコンポーネントとしてテストすることです。これは通常、他のコンポーネントのモックを作成することによって実現されます。また、一般的には、より大規模なテストだけで、単体テストライブラリを使用して実行されます。クラスごとに数十または数百の単体テストがある場合(主にクラスのサイズによって異なります)、システムの各コンポーネントに対して少数のコンポーネントテストがあります。

例として、データベースについて言及します。既定のデータを返すモックデータベースを作成し、モックを使用してデータベースとインターフェイスする部分をテストすることで、コンポーネントテストを行うことができます。テスト容易性が設計で懸念されるようになるため、これは単体テストよりも困難です。データベースがプログラムにハードコードされている場合、データベースをどのようにモックするかというようなことが起こります。それでも比較的簡単に行うことができますが、それはいくつかの予見と計画が必要なだけです。

システムテスト

システムを駆動するには統合ポイントが必要なため、システムテストはテストを作成するのが最も困難です。個人的なプロジェクトでは、特にユニットとコンポーネントのテストで徹底的な仕事をした場合は、おそらくシステムテストをスキップできます。

システムテストには、システム全体のシナリオを実行することが含まれます。特にUIアプリケーションの場合、ユーザー入力をシミュレートする方法が必要になるため、難易度は大幅に高まります。コンパイラのようなテキストベースのシステムでは、テキストを生成するだけですが、UIでは、入力を駆動するか、入力コールバックにテストフックを設定する必要があります。単体テストのように、すべてのソリューションに1つのサイズで対応できるわけではありません。

テストアドバイス

実際のテストは、業界に入る前のテストとはまったく異なります。学校に通っていたとき、「テスト」しているときに生産的だと思っていた非生産的なことをするのに多くの時間を無駄にしました。そうは言っても、ここに私のアドバイスがあります:

  1. 物事をバケツに入れて、バケツ全体にあなたの努力を広げてください。ストレス、パフォーマンス、ボーダーケース、定期的な入力、ローカリゼーション、UIなど、さまざまな側面を見てください。次に、追求する価値があるものとそうでないものを決定します。趣味のプロジェクトでは、ローカリゼーションは優先されない可能性があります。
  2. 物事をテストするためだけに物事をテストしないでください。テストを書くことを決定する前に、それが書く価値があるかどうかを決定してください。たとえば、500,000文字の文字列を入力として指定すると、Webサイトがクラッシュすることがわかった場合、それを修正しますか?それが些細な修正でなければ、私はそうしないだろうと私は知っています。そのため、テストケースは書く価値がありません。
  3. テスト対象のプログラムをコードの一部と考えてください。多くの人がブラックボックスビューを購読しています。このビューでは、実装の詳細について何も想定する必要はありませんが、それは非生産的だと思います。実装にとって意味があり、将来の実装にとっても意味のあるテストを作成します。これは、バグを見つけるのではなく、後でリグレッションをキャッチするという自動テストの目的に戻ります。
  4. 国境事件について考えてみてください。前述のようなコンテナクラスを作成している場合は、空のコンテナ、最大サイズのコンテナ(または最大サイズがある場合)、1つの要素を持つコンテナなどを検討する必要があります。通常のコンテナにはいくつかのテストが必要です。ケースとボーダーケースの場合はさらにいくつか。ただし、ここでは実用的であり、ポイント2を念頭に置いてください。

参考文献:

于 2012-10-16T04:02:23.813 に答える
0

「flasktest」をグーグルで検索すると、最初の項目が返されます:http: //flask.pocoo.org/docs/testing/

ユニットテストには、SQLite3のようなファイルシステムベースのデータベースを使用できると思います。

関数を検証する方法(テストケースでassertを記述する方法)に関しては、これは実際には関数が何をしているかによって異なります。特定のケースでは、少なくとも2つのテストケースが必要だと思います。1つはリストコメントが保存されているユーザー用で、もう1つはコメントが返されないと予想される不明なユーザー用です。

あなたはこのようなユニットテストを書く方法についてのいくつかのオンラインガイドに従うことから始めるかもしれません

于 2012-10-16T04:05:58.100 に答える