Pythonでのテスト：すべての主要なアプローチ、長所と短所。Yandexレポート

あなたの前にマリア・ゼレノヴァの報告があります ゼルマ--Foodilの開発者。マーシャは1時間、テストプログラムとは何か、テストとは何か、なぜそれらを書くのかを話しました。簡単な例を使用して、Pythonコード（unittest、pytest、mock）をテストするためのライブラリ、それらがどのように機能するか、およびそれらの違いについて学ぶことができます。





-こんばんは、私の名前はマーシャです。私はエディラのデータ分析部門で働いています。今日はあなたと一緒にテストについての講義をします。







最初に、一般的にどのような種類のテストがあるかについて話し合い、なぜテストを作成する必要があるのか​​を納得させようとします。次に、テストを直接操作するためのPythonの機能と、テストの作成モジュールおよび補助モジュールについて説明します。最後に、CIについて少しお話します。これは大企業での生活の必然的な部分です。







例から始めたいと思います。テストを書く価値がある理由を非常に恐ろしい例で説明しようと思います。



これがTHERAC25プログラムのインターフェースです。これは癌患者の放射線治療用の装置の名前であり、すべてが非常にうまくいきませんでした。まず第一に、それは悪いインターフェースを持っていました。彼を見ると、彼があまり良くないことはすでに理解できます。医師がこれらすべての数字を運転するのは不便でした。その結果、彼らは前の患者の記録からデータをコピーし、編集する必要があるものだけを編集しようとしました。



彼らが半分を修正するのを忘れて、間違っていたのは明らかです。その結果、患者は誤って扱われました。 UIもテストする価値があり、テストが多すぎることはありません。



しかし、悪いインターフェースに加えて、バックエンドにはさらに多くの問題がありました。私が最もひどいと思われる2つを特定しました。

• . , . , . , .
• C . THERAC , — , . . , , , - , - — .

テストを書く価値があるでしょう。それは5人の記録された死に終わったので、そして何人の人々があまりにも多くの薬を与えられたことで苦しんでいるのかは不明です。







状況によっては、テストを作成することで多くのお金を節約できるという別の例があります。これは火星気候オービターです。火星の大気中の大気を測定して、そこで気候に何が起こっているかを確認するための装置です。



しかし、地上にあったモジュールは、メトリックシステムのSIシステムでコマンドを実行しました。そして火星の軌道にあるモジュールは、それが英国の対策システムであると考え、それを誤って解釈しました。



その結果、モジュールは間違った角度で大気に入り、崩壊しました。テストで状況をシミュレートしてこれを回避することは可能であるように思われますが、1億2500万ドルがゴミ箱に入ったばかりです。しかし、それはうまくいきませんでした。



ここで、テストを作成する必要がある理由について説明します。各項目について個別に話しましょう：

• テストは、コードが機能することを確認し、少し落ち着かせます。テストを作成した場合は、コードが機能することを確認できます。もちろん、適切に作成した場合はそうです。よく眠れ。それは非常に重要です。
• . . , , , . , . , .
  
  
  
  , - , — , - . , . , , . , , , git blame, , , , .
• . , . , . , , . - - , - - . , , , . - .
• , . ? , , , , : , . 500 -, . . .
• : — . , , . , , .
  
  
  
  , , , . , , .
• . — , . , , . , .
  
  
  
  : - . , , . , , , - , .

ここで、テストの種類の分類について少しお話したいと思います。それらはたくさんあります。ほんの少しだけ言及します。



テストプロセスは、ブラックボックステスト、ホワイトテスト、グレーテストに分けられます。







ブラックボックステストは、テスターが内部の内容について何も知らない場合のプロセスです。彼は、普通のユーザーのように、実装の詳細を知らなくても何かをします。



ホワイトボックステストとは、テスターがソースコードを含む必要な情報にアクセスできることを意味します。自分のコードでテストを書くとき、私たちはそのような状況にあります。



グレーボックステストはその中間です。これは、実装の詳細をいくつか知っているが、すべてを知っているわけではない場合です。



また、テストプロセスは、手動、半自動、および自動に分けることができます。手動テストは人が行います。彼がブラウザのボタンをクリックし、どこかをクリックし、何が壊れているか、何が壊れていないかを確認するとします。半自動テストとは、テスターがテストスクリプトを実行することです。テストをローカルで実行する場合、このような状況にあると言えます。自動テストには人間の参加は含まれません。テストは手動ではなく自動的に実行する必要があります。



また、テストは詳細レベルで分割できます。ここでは通常、ユニットテストと統合テストに分けられます。不一致がある可能性があります。自動テストをユニットテストと呼ぶ人がいます。しかし、より古典的な区分はこのようなものです。



ユニットテストはシステムの個々のコンポーネントの動作をチェックし、統合テストはいくつかのモジュールのバンドルをチェックします。システム全体の動作をチェックするシステムテストもあります。しかし、これは統合テストの大きな変種のようです。



私たちのコードのテストは、ユニットテストと統合テストです。統合テストだけを書くべきだと信じている人がいます。私はその一人ではありません。すべてを適度に行う必要があると思います。1つのコンポーネントをテストする場合のユニットテストと、大きなものをテストする場合の統合テストの両方が役立ちます。



なぜそう思うのですか？ユニットテストは通常​​より高速だからです。何かを微調整する必要がある場合、「テストの実行」ボタンをクリックしてから、データベースが開始され、移行が行われるまで3分間待つと、非常にイライラします。何か別のことが起こります。このような場合、ユニットテストが役立ちます。それらは、一度に1つずつ実行して、すばやく便利に実行できます。しかし、ユニットテストを修正したら、統合テストを修正しましょう。



統合テストも非常に必要なものです。大きなプラスは、それらがシステムに関するものであるということです。もう1つの大きな利点は、コードのリファクタリングに対する耐性が高いことです。小さな関数を書き直す可能性が高い場合は、パイプライン全体を同じ頻度で変更する可能性はほとんどありません。







さらに多くの異なる分類があります。私がここに書いたことをすぐに説明しますが、詳細には触れません。これらはどこかで聞くことができる言葉です。



煙テストは重要な機能のテストであり、最初で最も単純なテストです。それらが壊れた場合、テストする必要はありませんが、修正する必要があります。アプリケーションが起動し、クラッシュしなかったとしましょう。すばらしい、スモークテストに合格しました。



回帰テストがあります-古い機能のテスト。新しいリリースをロールし、古いリリースで何も壊れていないことを確認する必要があるとします。これは回帰テストのタスクです。



互換性テスト、インストールテストがあります。彼らは、さまざまなOSとさまざまなOSバージョン、さまざまなブラウザとさまざまなブラウザバージョンで、すべてが正しく機能することを確認します。



受け入れテストは受け入れテストです。私はすでにそれらについて話しました、彼らはあなたの変更が本番環境にロールインできるかどうかについて話します。



アルファテストとベータテストもあります。これらの概念はどちらも、製品に関連しています。通常、リリースの準備ができているバージョンが多かれ少なかれあるが、すべてがそこで修正されているわけではない場合は、条件付きで外部の人々、または外部の人々、ボランティアにそれを渡して、バグを見つけて報告し、非常に優れたバージョンをリリースできるようにすることができます。アルファ版の完成度が低いほど、ベータ版の完成度は高くなります。ベータテストでは、ほとんどすべてが今では問題ないはずです。



次に、パフォーマンステストとストレステスト、負荷テストがあります。たとえば、アプリケーションが負荷をどのように処理しているかをチェックします。いくつかのコードがあります。ユーザー数、リクエスト数、RPS、1秒あたりのリクエスト数を計算しました。私たちはこの状況をシミュレートし、立ち上げ、見ました-それは成り立ちますが、成り立ちません。それが成り立たない場合は、次に何をすべきかを考えてください。おそらく、コードを最適化するか、ハードウェアの量を増やすために、さまざまなソリューションがあります。



ストレステストはほぼ同じですが、負荷が予想よりも高いだけです。パフォーマンステストで期待するレベルの負荷が得られた場合、ストレステストでは、負荷が壊れるまで負荷を増やすことができます。



リンターはここで別々に立っています。リンターについては少し後で説明します。これらはコードフォーマットテストであり、スタイルガイドです。 Pythonでは、誰もが従うべき簡単なスタイルガイドであるPEP8があります。そして、あなたが何かを書くとき、あなたは通常、コードに従うのが難しいことに気づきます。空の行を入力するのを忘れた、余分な行を作成した、または長すぎる行を残したとします。コードが同じスタイルで書かれていることに慣れているので、邪魔になります。リンターを使用すると、そのようなものを自動的にキャッチできます。



理論、すべて、それから私はPythonに何があるかについて話します。







これがいくつかのライブラリのリストです。それらすべてについては詳しく説明しませんが、ほとんどについては説明します。もちろん、unittestとpytestについても説明します。これらは、テストの作成に直接使用されるライブラリです。 Mockは、モックオブジェクトを作成するためのヘルパーライブラリです。彼女についても話します。 doctestはドキュメントをテストするためのモジュールであり、flake8はリンターです。これらについても説明します。ピラマとトックスについては話しません。あなたが興味を持っているなら、あなたはあなた自身のために見ることができます。ピラマはリンターでもあり、メタルインターでもあり、いくつかのパッケージを組み合わせており、非常に便利で優れています。また、さまざまな環境でコードをテストする必要がある場合、たとえば、さまざまなバージョンのPythonやさまざまなバージョンのライブラリを使用して、toxライブラリが必要になります。 Toxはこの意味で大いに役立ちます。



しかし、さまざまなライブラリについて話す前に、私は陳腐さから始めます。コードでassertを自由に使用してください。それは残念ではありません。多くの場合、何が起こっているのかを理解するのに役立ちます。







通常の統計を計算する関数があるとすると、2つのアサートが書き込まれます。アサートは、コードに含めるべきではない完全に極端なナンセンスである場合に、関数で記述する必要があります。これらは非常に極端なケースであり、ほとんどの場合、本番環境でそれらに遭遇することさえありません。つまり、コードを台無しにすると、テストで失敗する可能性が高くなります。



アサートは、プロトタイピングを行っているときに役立ちます。製品コードはまだありません。呼び出された関数のどこにいても、どこにでもアサートを固定できます。これは深刻なプロジェクトには適していませんが、プロトタイピングの段階ではかなり良いです。



なんらかの理由でassertを無効にしたい場合を考えてみましょう。たとえば、本番環境では決して起動しないようにします。 Pythonには、このための特別なオプションがあります。







doctestとは何かをお話しします。これはモジュールであり、ドキュメントをテストするためのPython標準ライブラリです。なんでいいの？コードで書かれたドキュメントは頻繁に壊れがちです。ここには非常に小さなおもちゃの機能があり、すべてを見ることができます。しかし、大きなコードと多くのパラメーターがあり、最後に何かを追加した場合、非常に高い確率でdocstringを修正するのを忘れてしまいます。 Doctestはこれらのことを回避します。何かを修正し、ここで更新せず、doctestを実行すると、クラッシュします。ですから、あなたは自分が何を訂正しなかったかを正確に覚えています。



それはどのように見えますか？ Doctestは、docstringでこれらのクリスマスツリーを探し、それらを実行して、取得したものを比較します。







doctestの実行例を次に示します。私たちはそれを立ち上げました、私たちは2つのテストがあり、そのうちの1つが完全にケースに落ちたことがわかります。すばらしい、明確なエラー情報がいくつか見られました。





^{_{スライドからのリンク}}



doctestには、役立つ可能性のあるいくつかの役立つディレクティブがあります。それらすべてについて話すわけではありませんが、私にとって最も一般的であると思われるものをスライドに載せました。 SKIPディレクティブを使用すると、マークされた例でテストを実行しないことができます。 IGNORE_EXCEPTION_DETAILディレクティブは、EXCEPTIONテストを無視します。 ELLIPSISを使用すると、出力のどこにでもエリプシスを書き込むことができます。 FAIL_FASTは、最初に失敗したテストの後で停止します。他のすべてはドキュメントで読むことができます、たくさんあります。例を挙げてお見せしたほうがいいです。







この例には、ELLIPSISディレクティブとIGNORE_EXCEPTION_DETAILディレクティブがあります。 ELLIPSISディレクティブにK番目の順序統計が表示されます。9で始まり9で終わる何かが来ると予想されます。真ん中に何かがある可能性があります。そのようなテストは失敗しません。



以下はIGNORE_EXCEPTION_DETAILディレクティブであり、AssertionErrorで発生したもののみをチェックします。ほら、そこに何とか何とか何とか書いた。テストは合格し、最初の引数として予想される反復可能と何とか何とか何とかを比較しません。 AssertionErrorをAssertionErrorと比較するだけです。これらはあなたが使うことができる便利なものです。







次に、計画は次のとおりです。unittestについて説明し、次にpytestについて説明します。それが標準ライブラリの一部であることを除いて、私はおそらくunittestの長所を知らないとすぐに言います。現在、unittestを使用せざるを得ない状況は見当たりません。しかし、それを使用するプロジェクトがあります。いずれにせよ、構文がどのように見えるか、そしてそれが何であるかを知ることは有用です。



もう1つのポイント：unittestで記述されたテストは、箱から出してすぐにpytestを実行する方法を知っています。彼は気にしない。 （…）



Unittestはこんな感じ。テストという言葉で始まるクラスがあります。内部では、単語テストで始まる関数。テストクラスはunittest.TestCaseから継承します。ここでの1つのテストは正しく記述されており、別のテストは正しくないことをすぐに言わなければなりません。



通常のアサートが書き込まれる一番上のテストは失敗しますが、奇妙に見えます。見てみましょう。







コマンドを開始します。 unittest mainはコード自体に記述でき、Pythonから呼び出すことができます。







このテストを実行したところ、AssertionErrorが書き込まれたことがわかりましたが、self.assertEqualを使用した次のテストとは異なり、どこに落ちたかは書き込まれませんでした。ここに明確に書かれています：3は2と等しくありません。







もちろん、修理する必要があります。しかし、この魔法の出力は画面に表示されませんでした。



もう一度見てみましょう。最初のケースでは、assertを記述し、2番目のケースではself.assertEqualを記述しました。残念ながら、これがunittestの唯一の方法です。特別な関数があります-self.assertEqual、self.assertnotEqual、および適切なエラーメッセージを表示したい場合に使用する必要がある100,500以上の関数。



なぜそれが起こるのですか？ assertはboolと、場合によっては文字列を受け取るステートメントですが、この場合はboolです。そして、彼は自分が正しいか間違っているかを見て、左側と右側をとる場所がありません。したがって、unittestには、エラーメッセージを正しく表示する特別な機能があります。



これは私の意見ではあまり便利ではありません。より正確には、これらはこのライブラリにのみ存在するいくつかの特別なメソッドであるため、まったく便利ではありません。それらは、私たちが通常の言語で慣れているものとは異なります。







これを覚えておく必要はありません。pytestについては後で説明します。ほとんどの場合、これに書き込んでいただければ幸いです。 Unittestには、何かをテストして適切なエラーメッセージを取得したい場合に使用する機能の動物園があります。



次に、unittestでフィクスチャを作成する方法について説明します。しかしそれをするために、私は最初にあなたに備品が何であるかを言う必要があります。これらは、テストの実行前または実行後に呼び出される関数です。テストで特別な設定を実行する必要がある場合に必要です。テスト後に一時ファイルを作成し、一時ファイルを削除します。データベースを作成し、データベースを削除します。データベースを作成し、それに何かを書き込みます。一般的に、何でも。 unittestでどのように見えるか見てみましょう。







Unittestには、フィクスチャを作成するための特別なメソッドsetUpおよびtearDownがあります。なぜまだPEP8に従って書かれていないのか、私には大きな謎です。 （...）



SetUpはテストの前に行われることであり、tearDownはテストの後に行われることです。これは非常に不便なデザインのようです。どうして？なぜなら、第一に、私の手はこれらの名前を書くために立ち上がらないからです。私はすでにPEP8がまだある世界に住んでいます。次に、テスト自体の引数に何も含まれていない一時ファイルがあります。彼はどこから来たのですか？なぜそれが存在するのか、そしてそれが何であるのかはあまり明確ではありません。



画面にしがみつく小さなクラスがあると、かっこいいです。一見してキャプチャできます。そして、あなたがこの巨大なシートを持っているとき、あなたはそれが何であったか、そしてなぜ彼がそのようであるのか、なぜ彼がそのように振る舞うのかを探すために苦しめられます。



unittestのフィクスチャには、それほど便利ではない機能がもう1つあります。一時ファイルを必要とする1つのテストクラスと、データベースを必要とする別のテストクラスがあるとします。優れた。 1つのクラスを作成し、setUp、tearDownを実行し、一時ファイルを作成/削除しました。別のクラスを作成し、その中にsetUp、tearDownを作成し、その中にデータベースを作成/削除しました。



質問。両方を必要とするテストの3番目のグループがあります。これをどうするか？ 2つの選択肢があります。または、コードをコピーして貼り付けますが、あまり便利ではありません。または、新しいクラスを作成し、前の2つから継承して、superを呼び出します。一般的に、これも機能しますが、テストでは大げさなやり過ぎのように見えます。







したがって、理論的なレベルでは、unittestについての知識をこのままにしておく必要があります。次に、テストを作成するためのより便利な方法、より便利なライブラリについて説明します。これはpytestです。



まず、pytestが便利な理由をお話しします。





^{_{スライドからのリンク}}



最初のポイント：pytestでは、アサートは通常は機能し、慣れているものであり、通常のエラー情報を提供します。第二に、pytestの優れたドキュメントがあります。ここでは、多数の例が分解され、必要なものはすべて、理解できないものすべてを表示できます。



第三に、テストはtest_で始まる関数にすぎません。つまり、追加のクラスは必要ありません。通常の関数を記述し、それをtest_と呼ぶだけで、pytestを介して実行されます。これは、テストを作成するのが簡単であるほど、スコアを付けるよりもテストを作成する可能性が高くなるため、便利です。



Pytestには便利な機能がたくさんあります。パラメータ化されたテストを作成できます。さまざまなレベルのフィクスチャを作成すると便利です。また、xfail、raise、skipなどの便利な機能もいくつかあります。 pytestには多くのプラグインがあり、さらに独自のプラグインを作成することもできます。







例を見てみましょう。これは、pytestで記述されたテストがどのように見えるかです。意味はunittestと同じですが、見た目がはるかに簡潔です。最初のテストは通常​​2行です。







コマンドpython-mpytestを実行します。優れた。 2つのテストに合格しました。すべて問題ありません。何に、いつ合格したかを確認できます。







それでは、1つのテストを中断して、エラーに関する情報が得られるようにします。アサート3 == 2およびエラーを出力します。つまり、通常のassertを記述したにもかかわらず、エラーに関する情報を正しく表示しましたが、その前にunittestで、assertは文字列またはboolのboolを受け入れると述べたため、エラーに関する情報を表示するのは問題があります。



なぜこれがすべて機能するのか不思議に思うかもしれません。 pytestで、彼らはインターフェースの醜い部分を試して整理したからです。 Pytestは最初にコードを解析し、それは一種のツリー構造、抽象的な構文ツリーとして表示されます。この構造では、頂点に演算子があり、葉にオペランドがあります。アサートは演算子です。それはツリーの最上部にあり、現時点では、すべてをインタープリターに渡す前に、このアサートを、イントロスペクションを実行し、左側と右側にあるものを理解する内部関数に置き換えることができます。実際、これはすでにインタープリターに供給されており、assertが置き換えられています。



詳細には立ち入りません、リンクがあります、その上であなたは彼らがそれをどのようにしたかを読むことができます。しかし、私はそれがすべて内部で機能することを愛しています。ユーザーには表示されません。彼は、彼が慣れているように、ライブラリ自体が残りを行うと主張します。あなたもそれについて考える必要はありません。



さらに、標準タイプのpytestでは、とにかく適切なエラー情報が得られます。 pytestはこのエラー情報を表示する方法を知っているからです。ただし、テストでカスタムデータタイプを比較することはできます。たとえば、ツリーや複雑なものなどです。pytestは、それらのエラー情報を表示する方法を知らない場合があります。このような場合は、特別なフックを追加できます（ここにドキュメントのセクションがあります）。このフックに、エラー情報がどのように表示されるかを記述します。すべてが非常に柔軟で便利です。







pytestでフィクスチャがどのように見えるか見てみましょう。 unittestでsetUpとtearDownを記述する必要がある場合は、ここで通常の関数を好きなように呼び出します。 pytest.fixtureデコレータを一番上に書きました-素晴らしい、それはフィクスチャです。



そして、これは最も単純な例ではありません。フィクスチャは単にリターンを実行し、何かを返すことができます。これはsetUpに類似しています。この場合、一種のティアダウンが発生します。つまり、ここで、テストの終了後にcloseが呼び出され、一時ファイルが削除されます。



便利そうです。好きな名前を付けることができる任意の関数があります。明示的にテストに合格します。渡されたfilled_file、あなたはそれが何であるかを知っています。特別なことは何も必要ありません。一般的には使用してください。これは、unittestよりもはるかに便利です。







フィクスチャについてもう少し。 pytestでは、さまざまなスコープのフィクスチャを作成するのは非常に簡単です。デフォルトでは、フィクスチャは機能レベルで作成されます。これは、合格したすべてのテストで呼び出されることを意味します。つまり、yieldまたはtearDownのようなものがある場合、これは各テストの後にも発生します。



scope = 'module'を宣言すると、フィクスチャはモジュールごとに1回実行されます。データベースを一度作成し、各テストの後にすべての移行をドロップアンドロールしたくないとします。



また、フィクスチャではautouse = True引数を指定することができ、要求したかどうかに関係なくフィクスチャが呼び出されます。このオプションは暗黙的なものであるため、絶対に使用しないでください。または使用する必要がありますが、非常に注意してください。暗黙的なものは避けるのが最善です。







このコードを実行しました-何が起こったのか見てみましょう。フィクスチャに依存するテストのものがあります。必要に応じて一度使用すると、毎回電話してください。同時に、モジュールレベルのフィクスチャが必要なときに使用したら、私に電話してください。初めてフィクスチャを呼び出したときは、必要に応じて一度使用すると、毎回電話をかけて出力しますが、自動使用のフィクスチャも呼び出されました。気にしないため、常に呼び出されます。



2番目のテストは、同じフィクスチャに依存します。モジュールレベルであるため、必要なときに一度使用すると2回目に呼び出すと、すでに1回呼び出されており、再度呼び出されることはありません。



さらに、この例から、あるテストではデータベースが必要な場合、別のテストでは一時ファイルが必要な場合に、pytestにはunittestで説明したような問題がないことがわかります。それらを通常どのように集約するかは明確ではありません。これがpytestでのこの質問への答えです。 2つの器具が渡された場合、内部に2つの器具があります。



素晴らしい、とても快適で、問題ありません。フィクスチャは非常に柔軟性があり、他のフィクスチャに依存する可能性があります。これには矛盾はなく、pytest自体が正しい順序でそれらを呼び出します。







実際、内部では、他のフィクスチャからフィクスチャを継承し、スコープを変えて、自動使用せずに自動使用することができます。彼自身がそれらを正しい順序で配置し、それらを呼び出します。



ここに最初のテストがあります。これはrare_dependency_for_test_oneに依存し、このフィクスチャは別のフィクスチャに依存します。排気ガスで何が起こるか見てみましょう。







継承順に呼び出されることを確認しました。すべての機能レベルのフィクスチャがあるため、テストごとにすべて呼び出されます。 2番目のテストはrare_dependencyに依存し、rare_dependencyはsome_common_dependencyに依存します。排気口を見ると、テストの前に2つの器具が呼び出されたことがわかります。



Pytestには、すべてのフィクスチャを配置できる特別な構成ファイルconftest.pyがあり、それを配置すると便利です。通常、人が他の人のコードを見るとき、彼は通常conftestのフィクスチャを調べに行きます。



それは義務ではありません。このファイルにのみ必要なフィクスチャがあり、それが特定の狭い範囲で適用可能であり、別のファイルでは必要ないことが確実にわかっている場合は、ファイルで宣言できます。または、多くのconftestを作成すると、それらはすべて異なるレベルで機能します。







pytestにある機能について話しましょう。私が言ったように、テストをパラメータ化することは非常に簡単です。ここでは、3つのパラメーターセットを持つテストが表示されます。2つの入力と1つの予期されるパラメーターです。それらを関数引数に渡し、入力に渡したものが期待されるものと一致するかどうかを確認します。







それがどのように見えるか見てみましょう。ここには3つのテストがあることがわかります。つまり、pytestはこれらが3つのテストであると考えています。 2つが通過し、1つが落ちました。ここで何がいいの？失敗したテストについては、引数が表示され、どのパラメーターセットで失敗したかがわかります。



繰り返しますが、あなたが小さな機能を持っていて、パラメータ化が3と言うとき、あなたはあなたの目で正確に何が落ちたかを見るかもしれません。しかし、パラメータに多くのセットがある場合、あなたはそれをあなたの目で見ることはできません。むしろ、あなたは見るでしょう、しかしそれはあなたにとって非常に難しいでしょう。そして、pytestがこのようにすべてを表示するのは非常に便利です-テストが失敗した場合はすぐにわかります。







パラメータ化は良いことです。また、一度テストを作成してから、多数のパラメーターセットを実行する場合、これは良い習慣です。同様のテスト用に多くのコードバリアントを作成するのではなく、一度テストを作成してから、パラメータの大規模なセットを作成すると、機能します。



pytestにはもっと便利なものがたくさんあります。それらについて話すと、明らかに講義だけでは不十分なので、もう一度、ほんの少しだけ紹介します。最初のテストでは、pytest.raises（）を使用して、例外が発生することを示します。つまり、この場合、AssertionErrorが発生すると、テストに合格します。例外がスローされるはずです。



2番目に便利なのはxfailです。テストを失敗させるデコレータです。たくさんのテスト、たくさんのコードがあるとしましょう。あなたは何かをリファクタリングしました、テストは失敗し始めました。同時に、それは重要ではないか、修理に非常に費用がかかることを理解しています。そして、あなたはこのようなものです：さて、私はそれにデコレータを掛けます、それは緑色に変わります、私は後でそれを修正します。または、テストが氾濫し始めたとします。これは自分の良識との合意であることは明らかですが、必要な場合もあります。さらに、この形式のxfailは、テストが失敗したかどうかに関係なく緑色になります。それでもStrict = Trueパラメーターに渡すことができます。そうすると、状況が少し異なり、pytestはテストが失敗するのを待ちます。テストに合格すると、エラーメッセージが返されます。その逆も同様です。



もう1つの便利なものはskipifです。テストを実行しないスキップがあります。そして、skipifがあります。このデコレータにカーソルを合わせると、特定の条件下でテストが実行されません。



この場合、Macプラットフォームを使用している場合は、何らかの理由でテストが失敗するため、起動しないと書かれています。それは起こります。ただし、一般に、特定のプラットフォームでは常に失敗するプラットフォーム固有のテストがあります。次に、これは便利です。







はじめましょうか。文字X、Sを見ました。ここでXはxfail、S-はskipifを指します。つまり、pytestは、完全に失敗したテストと実行したテストを示しますが、結果は確認しません。







pytest自体にはさまざまな便利なオプションがあります。もちろん、ここに表示することはできません。ドキュメントで確認できます。しかし、私はいくつかについてあなたに話します。



これは便利な--collect-onlyオプションです。見つかったテストのリストが表示されます。オプション-k-テスト名によるフィルタリングがあります。これは私のお気に入りのオプションの1つです。1つのテストが失敗した場合、特に複雑で修正方法がわからない場合は、フィルタリングして実行します。



あなたは時間を節約したいと思っており、おそらく他の15のテストを実行するのは楽しいことではありません。クラッシュするテストを実行し、修正して次に進みます。



非常に優れたオプション-sもあり、テストでstdoutおよびstderrからの出力を有効にします。デフォルトでは、pytestは失敗したテストに対してのみstdoutとstderrを出力します。ただし、通常はデバッグの段階で、テストで何かを出力したいが、テストが失敗するかどうかわからない場合があります。落ちないかもしれませんが、テスト自体で何が来て出力されるかを確認したいと思います。次に、-sを指定して実行すると、必要なものが表示されます。



-vは標準の冗長オプションであり、冗長性を高めます。



--lf、-last-failedは、最後の実行で失敗したテストのみを再起動できるオプションです。 --sw、-stepwiseも-kのような便利な関数です。テストを順番に修復する場合は、-stepwiseを使用して実行すると、緑色のテストが実行され、失敗したテストが検出されるとすぐに停止します。また、-swを再度実行すると、クラッシュしたこのテストから始まります。再び落下した場合は再び停止し、落下しなかった場合は次の落下まで移動します。





^{_{スライドからのリンク}}



pytestには、メインの構成ファイルpytest.iniがあります。その中で、pytestのデフォルトの動作を変更できます。ここでは、構成ファイルによくあるオプションを示しました。



テストパスは、pytestがテストを検索するパスです。 addoptsは、起動時にコマンドラインに追加されるものです。ここでは、addoptsにflake8とcoverageプラグインを追加しました。少し後で見ていきます。





^{_{スライドからのリンク}}



pytestにはさまざまなプラグインがあります。繰り返しになりますが、どこでも使用されているものを書きました。 flake8はリンターであり、カバレッジはテストによるコードカバレッジです。次に、pytest-flask、pytest-django、pytest-twisted、pytest-tornadoなどの特定のフレームワークでの作業を容易にするプラグインのセット全体があります。おそらく他に何かがあります。



xdistプラグインは、テストを並行して実行する場合に使用されます。タイムアウトプラグインを使用すると、テストの実行時間を制限できます。これは便利です。テストでタイムアウトデコレータをハングさせ、テストに時間がかかる場合は失敗します。







見てみましょう。 pytest.iniにcoverageとflake8を追加しました。カバレッジは私にレポートを与えました、私はそこにテストを含むファイルを持っています



、それから何かが呼び出されませんでした、しかしそれは大丈夫です:)これはk_stat.pyファイルです、それは5つものステートメントを含みます。これは、5行のコードとほぼ同じです。カバレッジは100％ですが、それは私のファイルが非常に小さいためです。



実際、カバレッジは通常100％ではなく、さらに、決して達成されるべきではありません。主観的には、60〜70％のテストカバレッジで十分であり、正常に機能しているようです。



カバレッジは、100％であっても、自分が優れているとは言えないほどの指標です。このコードを呼び出したという事実は、何かをチェックしたことを意味するものではありません。最後にassertTrueと書くこともできます。 100％のテストカバレッジにはフェージングとロボットがありますが、人々はそれを行う必要はありません。



pytest.iniで、もう1つのプラグインを接続しました。ここに--flake8があります。これは私のスタイルエラーを示すリンターであり、PEP8ではなくpyflakesからのものです。







ここの排気ガスには、PEP8またはpyflakesのエラー番号が書かれています。一般的に、すべてが明確です。行が長すぎます。再定義するには2行の空白行が必要であり、ファイルの最後に空白行が必要です。最後に、CitizenImportは私には使用されていないと書かれています。一般に、リンターを使用すると、重大なエラーやコード設計のエラーを検出できます。







タイムアウトプラグインについてはすでに説明しました。これにより、テストの実行時間を制限できます。一部のパフォーマンステストでは、実行時間が重要です。そして、time.timeとtimeitを使用してテスト内で制限できます。または、タイムアウトプラグインを使用します。これも非常に便利です。テストが機能しすぎる場合は、cProfileなど、さまざまな方法でプロファイルを作成できますが、Yuraは講義でこれについて説明します。







IDEを使用していて、補助ツールを使用する価値がある場合は、ここに特にPyCharmがあり、テストはIDEから直接実行するのが非常に簡単です。







モックについて話すことは残っています。モジュールAがあり、それをテストしたいのですが、テストしたくないモジュールが他にもあるとします。 1つはネットワークに接続し、もう1つはデータベースに接続し、3つ目はまったく煩わしくない単純なモジュールです。そのような場合、モックは私たちを助けます。繰り返しますが、統合テストを作成する場合は、テストデータベースを起動し、テストクライアントを作成する可能性が高く、それでも問題ありません。これは単なる統合テストです。



1つのピースだけをテストしたいときにユニットテストを実行したい場合があります。次に、モックが必要です。







モックは、実際のオブジェクトを置き換えるために使用できるオブジェクトのコレクションです。メソッドや属性を呼び出すと、モックも返されます。







この例では、単純なモジュールがあります。そのままにして、もっと複雑なものをモックに置き換えます。これがどのように機能するかを見ていきます。







ここにはっきりと示されています。私たちはそれを輸入しました、私たちはmがモックであると言います。モックを呼び戻した。彼らは、mには方法fがあると言った。モックを呼び戻した。彼らは、mがis_alive属性であると言いました。素晴らしい、別のモックが戻ってきました。そして、mとfが一度呼び出されることがわかります。つまり、これは非常にトリッキーなオブジェクトであり、その中でgetattrメソッドが書き直されます。







より明確な例を見てみましょう。 AliveCheckerがあるとしましょう。彼はある種のhttp_sessionを使用し、ターゲットが必要であり、受け取ったものに応じてTrueまたはfalseを返すdo_check関数を持っています：200または200ではありません。これは少し人工的な例です。しかし、do_checkの内部で複雑なロジックを完成させることができると仮定します。



セッションについて何もテストしたくない、getメソッドについて何も知りたくないとしましょう。 do_checkのみをテストします。よし、テストしてみよう。







あなたはこのようにそれを行うことができます。 http_sessionをモックします。ここではpseudo_clientと呼ばれます。彼女のgetメソッドをモックします。getは200を返すモックであると言います。起動し、これからAliveCheckerを作成し、起動します。このテストは機能します。



さらに、getが一度呼び出され、記述されたものとまったく同じ引数で呼び出されたことを確認しましょう。つまり、セッションが何であるか、またはそのメソッドが何であるかを何も知らずにdo_checkを呼び出しました。ただ凍らせただけです。私たちが知っている唯一のことは、それが200を返したこと







です。別の例。それは前のものと非常に似ています。ここでの唯一のものは、return_valueではなくside_effectです。しかし、それはモックが行うことです。この場合、例外がスローされます。アサート行は、AliveChecker.do_check（）ではなくアサートするように変更されました。つまり、チェックに合格しないことがわかります。



これらは、上から何が入ったのか、このクラスに入ったのかについて何も知らずにdo_check関数をテストする方法の2つの例です。







もちろん、この例は人為的なものに見えます。200であるかどうかにかかわらず、チェックが最小限のロジックである理由は完全には明らかではありません。しかし、リターンコードに応じてトリッキーなことをすることを想像してみましょう。そして、そのようなテストははるかに意味があるように見え始めます。 200が来るのを見て、処理ロジックをチェックします。 200でない場合-同じ。







ライブラリにモックでパッチを適用することもできます。すでにライブラリがあり、その中の何かを変更する必要があるとします。これが例です。サインにパッチを適用しました。今、彼はいつもデュースを返します。優れた。



また、mが2回​​呼び出されていることもわかります。もちろん、モックは、モックするメソッドの内部APIについて何も知りません。また、一般に、それらと一致する必要はありません。しかし、モックを使用すると、何を呼び出したか、何回、どの引数で呼び出したかを確認できます。この意味で、コードをテストするのに役立ちます。







モジュールが1つと巨大なモックしかない場合は警告したいと思います。すべてに合理的にアプローチしてください。簡単なものがある場合は、濡らさないでください。テストにモックが多ければ多いほど、現実から離れてしまいます。APIが一致しない可能性があり、一般に、これはテストしているものと正確には一致しません。あなたは必要なしにすべてを浸す必要はありません。プロセスにインテリジェントにアプローチします。







継続的な統合についての最後の小さな部分が残っています。ペットプロジェクトを単独で開発している場合は、ローカルでテストを実行できますが、大したことではありません。



プロジェクトが成長し、複数の開発者がプロ​​ジェクトに参加するとすぐに、プロジェクトは機能しなくなります。まず、半分はローカルでテストを実行しません。第二に、彼らは彼らのバージョンでそれらを実行します。どこかで衝突が起こり、すべてが絶えず崩壊します。



そのために、継続的な統合があります。これは、候補者を主流に迅速に注入することを含む開発手法です。しかし同時に、彼らは特別なシステムである種の自動組み立てまたは自動テストを経なければなりません。リポジトリにコードがあり、メインプロジェクトブランチにマージするコミットがあります。これらのコミットでは、テストは特別なシステムで合格します。テストが緑色の場合は、コミットが単独で注入されるか、コミットを注入する機会があります。



もちろん、そのようなスキームには、すべてだけでなく、欠点もあります。少なくとも、CIが無料になるという事実ではなく、追加のハードウェアが必要です。しかし、大企業ではなく、多かれ少なかれ大企業では、CIなしではどこにも行けません。







例として、CIの1つであるTeamCityのスクリーンショット。組み立てがあり、無事に完成しました。それに多くの変更がありました、それはそのようなそしてそのような時にそのようなそしてそのようなエージェントで立ち上げられました。これは、すべてが良好で、注入できる場合の例です。



多くの異なるCIシステムがあります。興味があれば、リストを作成しました。AppVeyor、Jenkins、Travis、CircleCI、GoCD、Buildbotです。ありがとう。

---

Pythonに関するビデオコースの他の講義は、Habréの投稿にあります。