8

最近、Python で GUI アプリケーションを開発しながら TDD を試しています。コードの機能を検証するテストがあることは非常に心強いことですが、TDD の推奨されるプラクティスのいくつかに従うのは難しいことです。つまり、最初にテストを書くのは大変でした。また、テストを読みやすくするのが難しいと感じています (モッキング ライブラリを多用しているため)。

私はmockerというモッキングライブラリを選びました。私がテストしているコードの多くは、(a) システム状態に依存するアプリケーション内の他のメソッド、または (b) イベント ループなしでは存在できない ObjC/Cocoa オブジェクトなどを呼び出すため、これをよく使用します。

とにかく、次のようなテストがたくさんあります。

def test_current_window_controller():
    def test(config):
        ac = AppController()
        m = Mocker()
        ac.iter_window_controllers = iwc = m.replace(ac.iter_window_controllers)
        expect(iwc()).result(iter(config))
        with m:
            result = ac.current_window_controller()
            assert result == (config[0] if config else None)
    yield test, []
    yield test, [0]
    yield test, [1, 0]

これは実際には 3 つのテストであることに注意してください。すべて同じパラメータ化されたテスト関数を使用します。テスト中のコードは次のとおりです。

def current_window_controller(self):
    try:
        # iter_window_controllers() iterates in z-order starting
        # with the controller of the top-most window
        # assumption: the top-most window is the "current" one
        wc = self.iter_window_controllers().next()
    except StopIteration:
        return None
    return wc

モッカーを使用して気づいたことの 1 つは、最初にアプリケーション コードを書き、次に戻ってテストを書く方が簡単だということです。呼び出しは、アプリケーション コードよりもはるかに冗長です (したがって、記述するのが難しくなります)。アプリ コードを記述し、それからテスト コードをモデル化する方が簡単です。

このテスト方法 (および少しの規律) により、100% のテスト カバレッジでコードを簡単に記述できることがわかりました。

これらのテストが良いテストであるかどうか疑問に思っていますか? 良いテストを書く秘訣を最終的に発見したとき、この方法を後悔するでしょうか?

テストが無駄になるほど、TDD のコア原則に違反していませんか?

4

3 に答える 3

8

コードを記述して合格した後にテストを記述している場合は、TDDを実行していません（テストファーストまたはテスト駆動開発のメリットも得られません。TDDに関する最も信頼のおける本については、SOの質問を確認してください。 ）。

モッカーを使用して気づいたことの1つは、ほとんどの場合、多くのメソッド呼び出しとモックを作成するための構文をモックしているため、最初にアプリケーションコードを記述し、次に戻ってテストを作成する方が簡単なことです。呼び出しは、アプリケーションコードよりもはるかに冗長です（したがって、書くのが困難です）。アプリコードを記述し、それからテストコードをモデル化する方が簡単です。

もちろん、特定の種類のブラシで空をペイントしてオレンジ色にした後、空がオレンジ色であることをテストしているだけなので、簡単です。これは（自己保証のための）改造テストです。モックは良いですが、いつどのように使用するかを知っておく必要があります-ことわざのように「ハンマーを持っていると、すべてが釘のように見えます」 -テストされます。テストが何であるかを理解するために費やされる時間は、壊れたものを修正するために使用できる失われた時間です。

そして重要なのは：

  • 読んでくださいモックはスタブではありません-まだ行っていない場合はマーティンファウラー。優れたModelViewPresenterパターン化GUIのいくつかの文書化されたインスタンスをグーグルアウトします（必要に応じてUIを偽造/モックアウトします）。
  • あなたの選択肢を研究し、賢く選択してください。左肩にハローを白くした男を「やらないで」と演じます。私の理由についてこの質問を読んでください-セントジャスティンはあなたの右肩にいます。彼にも言いたいことがあると思います:)
于 2008-09-17T04:33:46.390 に答える
-2

単体テストは、コードをリファクタリングするとき (つまり、モジュールを完全に書き直すか移動するとき) に非常に役立ちます。大きな変更を行う前に単体テストを行っている限り、終了時に何かを移動または含めることを忘れていないという確信が持てます。

于 2008-09-17T03:30:19.070 に答える
-3

TDDは万能薬ではないことを忘れないでください。それは難しいです、それは難しいはずです、そして「事前に」モックテストを書くことは特に難しいです。

だから私は言うだろう-あなたのために働くことをしなさい。それでも「認定TDD」ではありません。私は基本的に同じことをします。

コントローラコードとGUIライブラリコードの間に位置するGUI用の独自のAPIを提供することをお勧めします。それはモックするのが簡単かもしれません、あるいはあなたはそれにいくつかのテストフックを加えることさえできます。

大事なことを言い忘れましたが、あなたのコードは私にはあまり読めないようには見えません。モックを使用したコードは、一般的に理解しにくいものです。幸い、Pythonのモックは、他の言語よりもはるかに簡単でクリーンです。

于 2008-09-17T11:08:17.270 に答える