web-dev-qa-db-ja.com

Pythonでの動作駆動型開発とユニットテスト

Pythonでコード化されているユニットテストスイートをプロジェクトに組み込むことに関心があるかもしれません（そして、それがソリューションに関係している場合は、Redis、PostgreSQL、およびいくつかのサードパーティライブラリを使用します） ）達成したい利点は次のとおりです。

  1. プロジェクトがスピードアップしたら、コミュニケーションとチームの生産性を向上させるために、新しい行動を迅速かつ効率的に特定できるようにしたいと考えています。読む：BDDが必要ですが、BDDなしで既にコーディングを開始しています。
  2. 優れたテキストのサポート（つまり、テストはほとんど自然なテキストとして読み取ることができます）。これにより、テストの作成と読み取りが簡単になります。テスト。
  3. テストを自動的に実行する機能（少なくとも、Bashスクリプトなどで実行を含めることができるようにするため）。開発にはWindowsとLinux、Linuxサーバーを使用しているため、Linuxサポートが主な要件です。
  4. githubとの統合。可能かどうかはわかりませんが、githubで「合格」または「不合格」のステータスを持ついくつかのプロジェクトを見てきました。私たちのプロジェクトでそれができればすばらしいと思います。

これを行うのに役立つ優れたツール/ライブラリは何ですか？そして最も重要なこととして、BDDをPythonプロジェクトに組み込むための良い方法は何ですか？

どうもありがとうございました！任意の提案をいただければ幸いです。

pythontestingunit-testingbdd
7
Juan Carlos Coto

pyspecs を試してください。テストを読みやすくし、開発中に常に実行することは、このプロジェクトを作成する上での私の主な目標の2つでした。

テストコード：

from pyspecs import given, when, then, and_, the, this

with given.two_operands:
    a = 2
    b = 3

    with when.supplied_to_the_add_function:
        total = a + b

        with then.the_total_should_be_mathmatically_correct:
            the(total).should.equal(5)

        with and_.the_total_should_be_greater_than_either_operand:
            the(total).should.be_greater_than(a)
            the(total).should.be_greater_than(b)

    with when.supplied_to_the_subtract_function:
        difference = b - a

        with then.the_difference_should_be_mathmatically_correct:
            the(difference).should.equal(1)

コンソール出力：

# run_pyspecs.py

  | • given two operands 
  |   • when supplied to the add function 
  |     • then the total should be mathmatically correct 
  |     • and the total should be greater than either operand 
  |   • when supplied to the subtract function 
  |     • then the difference should be mathmatically correct 

(ok) 6 passed (6 steps, 1 scenarios in 0.0002 seconds)
5
mdwhatcott

レタスやビヘイビアなどのBDDフレームワークはありますが（ドキュメントとサンプルでより適切に選択できます）、それなしで開始したと述べました。だから私の答えはこの状況にもっと関連するでしょう。

オリジナルのBDDは、JUnitのフォークから始まりました。これは、テストに「testSomething」という名前を付けるように求める代わりに、「shouldDoSomething」という名前を付けるように求めてきました。それはあなたが物事に集中し続けることになっていた方法です。

だから私は自分のプロジェクトでも同じように行きました。私は「test_should _...」で始まるテストに名前を付け始め、わかりやすい名前を付けようとしました。これがBDDを実行する方法であり、テストが正確に何をすべきかに集中し、テスト名を通常の文に変換するものを書くのは簡単です（もちろん、必要な場合）。 （特にスクリプト言語では）役に立たない名前（BDDフレームワークの場合のテスト名など）に時間を費やしたくないので、このアプローチは特効薬だと思います。

4
Kostiantyn Rybnikov

私はC＃の Machine.Specifications に触発された Contexts と呼ばれるBDDフレームワークに取り組んできました。

Contextsは、テストケースをクラス全体に分散させることで、テストに対してユーザー中心の説明文（BDDの本質）を書くことを奨励します。テストの配置/実行/アサートフェーズは個々の短いメソッドに入れられ、コンテキストは名前に基づいてどのメソッドがどれであるかを判断します。

写真は千の言葉を話すので、readmeの例を次に示します。

import requests

class WhenRequestingAResourceThatDoesNotExist:
    def given_that_we_are_asking_for_a_made_up_resource(self):
        self.uri = "http://www.github.com/itdontexistman"
        self.session = requests.Session()

    def because_we_make_a_request(self):
        self.response = self.session.get(self.uri)

    def the_response_should_have_a_status_code_of_404(self):
        assert self.response.status_code == 404

    def the_response_should_have_an_HTML_content_type(self):
        assert self.response.headers['content-type'] == 'text/html'

    def cleanup_the_session(self):
        self.session.close()

コンテキストには、パラメーター化されたテスト、「アサーションの書き換え」（py.testに触発された）、プラグインフレームワークなどの多くの最新機能もあります。

私はコンテキストを使用して、それ自体だけでなく他のいくつかのプロジェクト（Python以外のプロジェクトも含む）をテストし、テスト用三角形のすべてのレベルで理解可能な動作テストを生成することを発見しました（受け入れ用に設計されていないユニットテストとは異なります）テスト、または単体テスト用に設計されていないレタス）。

2
Benjamin Hodgson