edx-platformに機能を追加した開発者のほとんどは、 モジュールストアテストケースコースウェアのコンテンツに関連するテスト（空のコースを作成するだけのテストでも）を実行する場合、このクラスを継承することで、個々のテスト間でデータが適切にクリーンアップされることが保証されます。これは非常に有益ですが、多くの状況では無駄になることもあります。先週のハッカソンでは、 より速い代替手段 呼ばれます 共有モジュールストアテストケース.
取消 モジュールストアテストケース, 共有モジュールストアテストケース するだけ モジュールストア 清掃 ティアダウンクラス() レベル。これは、1つまたは少数のコースを事前に初期化し、その後、多くのテスト間で読み取り専用で共有できる状況での使用を想定しています。この使用パターンは、LMSテストでよく見られ、多くの場合、同じコースを何度も繰り返し作成するだけです。 設定（） 方法。
パフォーマンスへの影響
効果の程度を把握するため、ハッカソンの一環としていくつかのテストモジュールを切り替えてみました。これは比較的少数のJenkinsテスト実行に基づいた概算値です。とはいえ、結果は期待できるものでした。
| File | # テスト | 作業前 | 後 | デルタ |
| lms/djangoapps/ccx/tests/test_ccx_modulestore.py | 5 | 38s | 4s | -89％ |
| lms/djangoapps/discussion_api/tests/test_api.py | 409 | 2m 45s | 51s | -69％ |
| lms/djangoapps/teams/tests/test_views.py | 152 | 1m 17s | 33s | -57％ |
では、独自のテストを変換するにはどうすればよいでしょうか?
スイッチを作る
継承するクラスのほとんどは モジュールストアテストケース 次のように始めます:
変更する場合 セルフコース 個々のテスト関数でこれが完璧であり、引き続き使用する必要があります。 モジュールストアテストケースただし、コースを一度だけ設定し、テストでは読み取り専用として扱う場合は、代わりに次のようにすることができます。
Django ORM操作は 設定（）で作成したモデルは setUpClass() 手動で削除する必要があります ティアダウンクラス() 方法 - 共有モジュールストアテストケース 適切にクリーンアップされません。たとえ注意を払っていたとしても、シーケンスやデータ設定時に生成されるIDについて誤った仮定をしているため、システム内の他のテストを予期せぬ形で壊してしまう可能性があります。これはデバッグが非常に面倒になる可能性があります。
Django 1.8にアップグレードすると、 テストデータ設定() Djangoモデルのクラスレベルの初期化を安全に自動クリーンアップで実行します。アップグレードを待って、モデル操作を 設定（） 今のところ、少し遅くても大丈夫です。
どのテストを変換すればよいですか?
テストの最適化対象を探すのに最も簡単な場所は Jenkinsテストビルドレポート「期間」をクリックすると、その列で並べ替えることができます。
主に、複雑なコースデータ（CCXなど）を作成する、またはコースデータはシンプルだがテストが非常に多い（ディスカッションなど）ような、コストの高いテストをターゲットにしたいと考えています。最もシンプルなコースの作成でも250～300ミリ秒ほどかかるため、以下のようなツールを使うと、この時間がかなり長くなります。 DDT クラス内のテストの数を実質的に増やします。
全体的なポイント
データベースアクセスはテスト実行においてコストのかかる部分であり、 モジュールストア その好例です。 共有モジュールストアテストケース テスト実行時間を短縮するのに役立つツールになり得ます。しかしそれ以上に、それがなぜ機能するのかを理解することで、より高速なテストスイートを全体的に設計できるようになることを願っています。
デイブ・オームズビーはedXのシニアアーキテクトです。この記事は元々彼のブログに掲載されたものです。 スワンプ城.
