2009-11-18 1 views
37

私は、大規模なPythonベースのApp Engineプロジェクトに着手しようとしています。ユニットテスト戦略を実行する前に、Stack Overflowの "群衆の知恵"をチェックする必要があります。私は、使用したい既存のユニットテストフレームワーク(unittestにカスタムランナーと拡張機能を使用)を使用していますので、nosewebtest、またはgaeunitのような "重い"/"介入"のようなものは適切ではないようです。私の世界観における重要な単体テストは非常に軽量で速いもので、非常に短時間で実行されるので、私は開発リズムを崩さずに何度も繰り返し実行することができます(例えば、別のプロジェクトでは典型的な走行のために5〜7秒、経過時間を要した数十回の超高速試験を伴う20Kラインプロジェクトでは97%ほどのカバレッジがあります。これは、テスト)。もちろん、セレンや風車との統合テストに至るまで、より豊富な/より重いテストもあります。ではありません。私はこの質問(と私の大部分の私の焦点開発の努力;-)は、軽くて素早く自分のコードをカバーする、小さく軽いユニットテストです。App Engineでの軽量Pythonユニットテストにどのようなアプローチを使用しましたか?

私は、データストア、memcache、リクエスト/レスポンスオブジェクト、webappハンドラ、ユーザ処理、メール、&などのさまざまな主要なApp Engineサブシステムの基本的な小型軽量シミュレーションのセットを考えています。 c、おおよそこの優先順位の順です。私が探しているものを正確に見つけられなかったので、私は過去にしばしばやったように、moxに頼るべきです。これは、基本的に、特定のテストで使用された各サブシステムを嘲笑してセットアップすることを意味しますすべての期待& c(たいていは大変な作業ですが、テストコードの内部構造に非常に敏感です、つまり非常に「ホワイトボックス」y)、または各サブシステムの独自のシミュレーションをローリングします(そしてシミュレートされたサブシステムユニットテストの一部としての状態)。 GAEのPython側の強力な「スタブ」アーキテクチャを考えれば、レイターは実現可能なようですが、私は自分自身をロールバックする必要があるとは思えません。つまり、誰も既にそのようなシンプルなシミュレータを書いているわけではありません!私が必要とするのは、SDKにすでに含まれている「データストア上のファイル」スタブであり、データストアの状態に関するアサーションのために読み取り専用で使いやすいアクセサをマークする方法です。サブシステムごとのサブシステム - 既存の「スタブ」アーキテクチャの「上に位置する」SDKに既に含まれているものよりも「ちょっとだけ」が必要なようです。

ユニットテストのためのGAEサブシステムのシミュレーションを「自分自身で実行する」貴重な開発時間の1日か2日を費やして過ごす前に、私はSO人の観客をもう一度チェックし、これを考えてみてください。あるいは、もし私が単純に再利用できる(または最小限に微調整することができ、私の検索で見つけられなかった)シミュレータの既存のオープンソースセットがすでに存在するなら -

を編集してください:私が自分自身をロールすると、実行可能であれば、SDK提供のスタブを活用する予定です。たとえば、最初にファイルから読み込まれた後に最後には保存されないデータストアのスタブがないため、既存のものをサブクラス化して調整する必要があります(これは、特に便利な方法を提供しません)。状態 - メールサービススタブなどと同じ)。 !それは私が「自分をロール」によって何を意味するかだ - 「ゼロからの書き換え」ではない - )

編集:「なぜGAEUnitない」 - GAEUnitは独自のユースケースのための素晴らしいですが、dev_appserverを実行していると見て私のブラウザ(またはurllib経由でさえ)になります。urlopen)は私が後にしたことではありません - 私は、ユニットテストを拡張することに基づいた既存のテスト実行フレームワーク内で実行するのに適した完全自動化セットアップを使用したいと思います。私たちはこれらをシミュレートしたり模擬しているので、gaeunitを使って "中"のテストよりもうまくいくわけではありません。+それぞれのデータストアをあらかじめ用意しておくのは便利な方法ではありませんテスト(そして、物をカスタマイズするのに役立つOO構造はありません)。

+0

2014年に群衆の意見は何ですか? – andruso

+0

@andrusr、私は長年にわたって 'google.appengine.ext.testbed'をうまく使ってきました。 –

答えて

13

プロダクションAPIをエミュレートするために使用するものであるため、独自のスタブを記述する必要はありません。SDKにはスタブが含まれています。それらのすべてが単体テストでの使用に適しているわけではありませんが、ほとんどがユニットテストでの使用に適しています。組み込みのスタブを使用するために必要なsetup/teardownコードの例については、this codeを参照してください。

+1

確かに、SDK提供のスタブを利用可能にする予定です。たとえば、最初にファイルから読み込まれた後に最後には保存されないデータストアのスタブがないため、既存のものをサブクラス化して調整する必要があります(これは、特に便利な方法を提供しません)。状態 - メールサービススタブなどと同じ)。それは私が「自分のものを揺さぶる」という意味です(この説明を追加するために質問を編集させてください)。 –

+1

でも、あなたが指しているコードはスタブを整理する方法の良い例です(そして、さらにカスタマイズしやすいようにOOしてください)。 –

+0

前者の場合、後でデータストアファイルを消去することができますテストの前にコピーしてください。または、初期データ用に必要な場合は、セットアップ機能でデータストアを作成します。データストアの状態をアサートするのは、単にクエリを実行して結果をチェックするケースです。しかし、他のスタブはあまり親切ではないので、ユニットテストには適していません。 –

4

私はGoogle App Engine AppにGAEUnitを使用しています。私はテストのスピードに満足しています。私がGAEUnitについて気に入っているのは、Webtestがやっていることです。テスト用にすべてのスタブ用の独自のバージョンを作成し、テスト用に "ライブ"バージョンのみを残しておくことです。

開発用に使用している可能性のあるデータストアは、GAETestを実行するときにそのまま残されます。

+1

dev_appserverを実行し、私のブラウザ(またはurllib.urlopen経由でも)で結果を見るのは、間違いなく私が行っていることです。私は、完全に自動化された設定を使用したいです。これは、既存のテスト実行フレームワークユニットテストを拡張し、HTTPを使用しません(このフレームワークでは、ソケットと最小限のディスクI/Oを実行する「高速」テストが定義されています)ので、gaeunitを使用して、 「中」テストよりも)+各テストでデータストアを事前入力する便利な方法はありません。 –

+0

それでも、他のニーズ(風力発電の全重量ではなく、HTTPラウンドトリップが必要な中規模+半統合テスト)のための素晴らしいフレームワークなので、ありがとう、+1 ;-) –

5

NoseGAEは、開発環境とテストデータストアを自動的に設定することによってunittestをサポートするノーズプラグインです。 dev_appserverで開発する場合に非常に便利です。

3

また、Fixtureが私の単体テストで非常に役立っていると付け加えることがあります。宣言構文でモデルを作成し、テストで読み込むことができる格納されたエンティティに変換することができます。このようにして、すべてのテストケースの始めに同じデータセットが作成されます。これにより、すべてのテストの開始時に手動でデータを作成する必要がなくなります。ここでの例では、フィクスチャのドキュメントから、次のとおりです。 はこのモデルを考える:

from google.appengine.ext import db 

class Entry(db.Model): 
    title = db.StringProperty() 
    body = db.TextProperty() 
    added_on = db.DateTimeProperty(auto_now_add=True) 

あなたのフィクスチャは、次のようになります。

from fixture import DataSet 

class EntryData(DataSet): 
    class great_monday: 
     title = "Monday Was Great" 
     body = """\ 
Monday was the best day ever. 
""" 

注しかし、私は次の問題に遭遇したこと: 1。 This bugが含まれていますが、付属のパッチはこれを修正します。 2.データストアは、デフォルトではテストケース間でリセットされません。だから私は、各テストケースのためのリセットを強制するためにこれを使用する:ビルドでunit test frameworkがある

class TycoonTest(unittest.TestCase): 
    def setUp(self): 
     # Clear out the datastore before starting the test. 
     apiproxy_stub_map.apiproxy._APIProxyStubMap__stub_map['datastore_v3'].Clear()  
     self.data = self.load_data() 
     self.data.setup() 
     os.environ['SERVER_NAME'] = "dev_appserver" 
     self.after_setUp() 

    def load_data(self): 
     return datafixture.data(*dset.__all__) 

    def after_setUp(self): 
     """ After setup 
     """ 
     pass 

    def tearDown(self): 
     # Teardown data. 
     try: 
      self.data.teardown() 
     except: 
      pass 
+0

Hmm。なぜこれが下落したのか分かりません。 – mahmoud

0

1.3.1 version of SDKので。

それだけ、今のJavaですが、私は好きな感じ:

  1. それはずっとあなたがあなたの質問にについて話と同じである(とはるかに - 例えばクラウドでテストを実行しているとして)
  2. Max Rossと彼は明示的に"Testing techniques for Google App Engine"

    彼のI/Oのプレゼンテーションでそれについて教えてくれる - \ SDK

を使ってPythonで同じように実装するので、このフレームワークの作者を行いポートにかなり可能です

誰でもこのトピックに関する最新情報をお持ちですか?

関連する問題