3

私は約6週間Pythonを学ぼうとしています。このサイトで TDD についてたくさん読んだ後、Roy Osherove によるThe Art of Unit Testing (すばらしい本です!) を購入して、Python を学びながら TDD を試してみました。この本は .NET を使用していますが、問題はないようです。スタブはスタブであり、モックはモックです。

TDD の例をオンラインで読んだり見たりしているうちに、コーダーがコードを書いた理由が理解できたような気がします。しかし、座って自分自身を試すとすぐに、どこにも行きません。

昨日の例を挙げましょう。

それほど複雑ではないプロジェクトで TDD を試してみたかったのです。基本的に、私が欲しいのは、RSS フィードをダウンロードして解析することにより、(name, date) を含むタプルのリストを保持するクラスです。テスト用に新しい py ファイルを作成し (「実際のコード」はまだ作成していません)、テスト ケースを作成しました。

import unittest

from tv_schedule import TvSchedule

class TvScheduleTests(unittest.TestCase):
    def test_download_success_and_parse_failure(self):
        '''Successfully download RSS schedule for the specific user
           but fail parsing it'''
        self.tv = TvSchedule("User123")
        # Check if ParserException was thrown I guess


if __name__ == "__main__":
    unittest.main()

...そして、私はちょっと立ち往生しています。と思います(笑)。これが単にばかげているかどうか、および/またはこれをより適切に行う方法について、いくつかの指針が本当に必要です。私の直感は、私が何か悪いことをしたと言っています。

TvSchedule クラスに ( feedparserを使用して) バックグラウンドでダウンロード/解析を実行させたいので、クラスの新しいインスタンスを作成してから使用するだけです。たぶんこれは悪い設計であり、テストも難しくなっていますか? また、ネットワーク経由で rss フィードを取得することへの依存をどのように削除しますか? それをスタブ化して、常にサンプル フィードを含むメモリ内文字列を返すことによって?

TDD のチュートリアルや書籍でよく使われている非常に単純な電卓の例を離れるとすぐに、行き詰ってしまいます。:(

4

3 に答える 3

4

あなたが遭遇するかもしれない一つの挑戦はあなたのテストが単に広すぎるということです。一度にダウンロードして解析するということは、たくさんのコードを書くことになるということです。最初のテストを少し絞ってみてください。それはあなたにいくらかの焦点を与えるのを助けるかもしれません。

もう1つの課題は、ロジックがあまりないコードを記述していることです。ダウンロードとRSS解析を行うために他のライブラリに委任しているだけです。これにより、問題を解決することが困難になります。その場合、これは練習しようとするのにかなり面白くない例かもしれません。ConwayのGameofLifeのようなものを、興味深いがより単純な問題として試乗することを検討してください。

お役に立てば幸いです。

ブランドン

于 2012-05-10T14:42:33.497 に答える
2

noseとを見る必要があると思いますmock。

noseはテストに適したモジュールであり、補完性がunittest高く、テストを実行するためのCLIコマンドを提供し、プラグインを使用してテストプラットフォームの結果（コードカバレッジなど）に関する詳細情報を提供します。

mockこれは、メソッドまたはオブジェクトをスタブまたはモックする方法であり、HTTPリクエストや、テストの範囲外のサービスと対話するオブジェクトなどに特に役立ちます。

あなたの例では、フィーダーオブジェクトにパッチを適用し、戻り値をいくつかのエッジケースに設定し、、（から継承された）などでケースが正しく処理されることを確認するためにテストself.assertTrueしself.assertIsInstanceますunittest.TestCase。

通常、使用中にPythonでTDDを実行する場合、nose最初unittestにTestCaseのスケルトンをaで記述し、setUp場合によってtearDownは一般的なモックとスタブを処理するaを使用します。定義するテストメソッドごとに、最初に必要なものをモックし、単体テストの周囲に環境を設定してから、メソッド/オブジェクトを呼び出してアサーションを作成します。

従来のTDDでは、最初にテストを設計してから、テストをグリーンにするためのコードを作成します。赤->緑。

于 2012-05-10T14:04:36.670 に答える
2

テストのタイトルに「and」が含まれている場合は常に、2 つのことをテストしています。一度に 1 つずつテストする方がはるかに良いので、テストを 2 つにリファクタリングすることをお勧めします。

第二に、本当に小さなステップで進みたいと思っています。次に実行できる最小のことを考えてみてください。それは現在のコードベースでは機能しません。

通常、コードがない場合、可能な限り最小のことは、ターゲット クラスの例を作成することです。何もするように頼むのではなく、ただ作成してください。

これは、あなたが置かれている状況とほとんど同じです。

TvSchedule がないため、コードはコンパイルされません。「未コンパイル」は赤としてカウントされます。コンパイルするコードを書いてください。それが Green です。わーい！

他の人が指摘したように、小さな TODO リストをどこかに保管しておく必要があります。Kent Beck の本では、付箋を使用しています。テスト コード ファイルに TODO リストを含めるのが好きです。Todo リストの範囲は、30 分または 2 時間など、費やす予定の時間内に達成しようとするものでなければなりません。一日中ではなく、今から次の休憩までです。次に、TODO リストに項目を追加したり、削除したりします。次に行う「失敗する可能性のある最も単純なこと」に集中するのに役立ちます。

[編集: TODO リストを追加]

于 2012-05-11T00:41:17.877 に答える