Let’s try pytest! 手軽なpytestでテストを活用しよう！
15.8K Views
December 17, 22
スライド概要
書籍『テスト駆動Python第2版』と、Pythonのテスティングフレームワークpytestを紹介しています。みんなのPython勉強会#88での発表資料です。
関連スライド
各ページのテキスト
Let’s try pytest! 手軽なpytestで テストを活用しよう！ やっとむ こと 安井 力 アジャイルコーチ 合同会社やっとむ屋 代表 Copyright© 2022 by 安井力、合同会社やっとむ屋 [email protected] 1
やっとむ / 安井力(やすいつとむ) 2001年ごろアジャイルと出会い、開発者、チームリーダー、トレー ナー、導入支援と多様な立場で関わってきた。(株)永和システム マネジメントにて2010年頃からアジャイルコーチを主軸として 活動。2014年独立。 著書・訳書 プログラマー Python JavaScript Java C/C++ アジャイルコーチ (プロセス面) チームビルディング 現場導入支援 スクラムマスター支援 ふりかえり アジャイルコーチ (ものづくり面) モブプログラミング テスト駆動開発 テスト自動化 学びのゲームをデザイン、製作、デリバリー 宝探しアジャイルゲーム カンバンゲーム 心理的安全性ゲーム [email protected] twitter:@yattom https://www.facebook.com/yattom https://www.linkedin.com/in/yattom/ 2
やっとむ / 安井力(やすいつとむ) 2001年ごろアジャイルと出会い、開発者、チームリーダー、トレー ナー、導入支援と多様な立場で関わってきた。(株)永和システム マネジメントにて2010年頃からアジャイルコーチを主軸として 活動。2014年独立。 著書・訳書 プログラマー Python JavaScript Java C/C++ アジャイルコーチ (プロセス面) チームビルディング 現場導入支援 スクラムマスター支援 ふりかえり アジャイルコーチ (ものづくり面) モブプログラミング テスト駆動開発 テスト自動化 学びのゲームをデザイン、製作、デリバリー 宝探しアジャイルゲーム カンバンゲーム 心理的安全性ゲーム [email protected] twitter:@yattom https://www.facebook.com/yattom https://www.linkedin.com/in/yattom/ 3
“pytest”の本 • pytestはPython用テスティングフレームワーク • Pythonで書いたコードに、Pythonでテストを書ける • いま一番ポピュラー だいたい2位 • 1位のRobotはRPA用で、性質が違う • シンプルかつ拡張性が高い • 色々なOSSやフレームワークで採用 ※pytest ← 全部小文字が正式名称 4
“pytest”の本 • 2022年8月出版の第2版 • 第1版は2018年 • 最新の内容(7.0)に対応 • 「テストを書くには？」という観点から機能を紹介 • 著者のBrian Okkenはテストエンジニア • 実践からのテクニックを豊富に紹介 • 第7章「戦略」が良い • 開発者とテスターの橋渡しになる 5
2019年 Stapy #46 6
2019年 Stapy #46 時間があれば… ライブコーディングで テスト駆動開発デモ！ 時間なかったら懇親会で！ → なかった
リベンジ！
お題: 数値データを処理する • CSVファイルを読む • SKU ID, 商品名, アクセス数 • 壊れてる行を取り除く • アクセス数(3カラム目)の平均を出力する • 外れ値を取り除く(最大値と最小値) • アクセス数(3カラム目) が平均を超える行をすべて出力する 9
ライブコーディング おわり
パンパイプ
書き方がシンプル • ファイル名を test_*.py か *_test.py にする • メソッド名を test_ で始める • カスタマイズ可能 https://docs.pytest.org/en/7.2.x/example/pythoncollection.html#changing-naming-conventions • 普通のassertを使う • Testで始まるクラスでまとめる • 入れ子も可能 • pytest-describeも便利そう https://is.gd/5vT3ZO 12
失敗時の表示が懇切丁寧 • 呼び出しや計算の結果がわかる • 文字列のdiffが見やすい 13
失敗時の表示が懇切丁寧 • dictやlistも テスト内容が込み入ってるときは便利！ 14
例外もテストできる • pytest.raises()で例外クラスを指定 • withで書けてかっこいい！ • matchパラメータでエラーメッセージも指定できる • 正規表現なので注意 15
フィクスチャがめちゃ便利 • テストの前提となるデータを外出しする • テストケース間での共有も一発 • xUnit系のsetup(), teardown()に似ているが、柔軟性 が段違い @pytest.fixtureを つけたメソッドが テストのパラメータ名で 自動で呼び出される 16
フィクスチャがめちゃ便利 • データベース接続やファイルなどのリソースを共用で きる returnの代わりに yieldを使えば 後始末も簡単 17
一時ディレクトリもフィクスチャ • tmp_path, tmp_path_factory • 一時ディレクトリをテスト用に作る • ファイル操作するテストに便利 • 終了後もしばらく残っている (何回分か) • capsys • 標準出力やエラー出力をassertできる • 表示のテストはわりと面倒なので便利 • monkeypatch • テスト用にコードを一時的に上書きできる • その他にも組み込みフィクスチャあります 18
パラメータ化テストが簡単 • 同じテストをいろいろなパターンのデータで実行 ・3 * 2 == 6 ・‘abc’ * 2 == ‘abcabc’ ・[1, 2, 3] * 2 == [1, 2, 3, 1, 2, 3] 19
パラメータに名前付けると見やすい • 使わない引数で名前を表現 • 他にもいくつかやり方があり 「16章 高度なパラメータ化」に詳しく書いてます！ (宣伝) 実行結果 20
フィクスチャもパラメータ化できる 実行結果 3つのDBそれぞれ 呼ばれている 21
書籍の他のトピック • 4章 組み込みフィクスチャ • 6章 マーカー • 8章 設定ファイル • 9章 カバレッジ • 10章 モック (テスト対象の依存関係をコントロールするテクニック) • 11章 toxと継続的インテグレーション • 13章 テストの失敗をデバッグする • 14章、15章 プラグインの利用と自分で作る方法 • 16章 複雑なパラメータ化 22
テストと仲良くなろう 23
自動テストはプログラマーの味方 • 自分が書いたコードの客観的な確認、検証 • 自分のミスを教えてくれる • 足を踏み外したとき救ってくれる安全ネット • 自分の仕事を自分で完結できる • ユーザーやクライアントへの責任 • チームの仲間への信頼 24
自動テストはチームの味方 • CIと組み合わせると、壊れたとき正確に、すぐにわかる • 遅くなればなるほど対応が大変 • 技術的負債に立ち向かう足場 • テストがあれば(比較的)安心してリファクタリングできる • 仕様もテストで表現できる 25
どんなテストが欲しい？ • テストの範囲 • 機能と非機能(セキュリティ、パフォーマンス、など) • コンポーネントテスト(単体テスト)とE2Eテスト • テストする機能を選ぶ • Recent / Core / Risk / Problematic / Expertise • テストケースの作り方 • 正しく動くことを確認する • 隠れた問題をあぶり出す 26
テストピラミッド https://appresso.hatenablog.com/entry/2016/10/17/125811 27
テストは具体例 • 仕様の言葉は抽象的 • テストケースは具体的な値 • 難しい問題、複雑な問題は具体例で考えたい • 「あーだったらこうなって、そーだったらあーなって」 • 「あれ、こーだったらどうなるんだっけ？」 28
抽象的 「国民の祝日」は、休日とする。 2.「国民の祝日」が日曜日に当たるときは、その日後においてその日に 最も近い「国民の祝日」でない日を休日とする。 3.その前日及び翌日が「国民の祝日」である日（「国民の祝日」でな い日に限る。）は、休日とする。https://www8.cao.go.jp/chosei/shukujitsu/gaiyou.html 具体的 https://www.nippon.com/ja/japan-data/h00443/ 29
プロダクトコードとテストコードを並行に書く • テスト駆動開発 (TDD; Test-Driven Development) • 厳密にテストファーストじゃなくても役立つ • その日のうちにはテストを書こう • 「だいじょぶかな？」とチラッと思ったら、テストを書く • 「動くかな？」という不安を「ほら動いた」という安心に 不安 安心 30
変更するためにテストを書く • 機能の追加変更のとき、まずテストを書く (テストファースト) • 新しい仕様をよく理解できる • どんな影響があるか、見通しがつく • コード変更の思わぬ影響を防ぐ • テストに守られたリファクタリング • 変更を安全に加えられる 31
リファクタリングでいいポジションをキープ 追加変更が容易で 意図しない問題も 起きにくい 安全な領域 高品質 内部 品質 低品質 相応の 手間・コストは 必要 追加変更が大変で 意図しない問題が すぐ起きる 苦しい領域 重力に 打ち克つ gravity 重力 時間
機能変更時のリファクタリング • これからさわるコードをきれいにする • メソッド名、変数名 • インデント • コメント • 変更しやすいように設計も見直す 大 • 「動くコード」を保証するテストが前提
テストコードもメンテナンス • 不要なテストは消す • 「不要」と判断できるのは、書いたすぐあと、書いた人だけ • 後で見て分かるように整理する • 仕様の言葉を使ってテスト名を付け直す • なんでこのテストケースがあるのか表現する(Why) 和田卓人さん(t-wada)による ライブコーディング動画もオススメ https://youtu.be/Q-FJ3XmFlT8?t=1145 34
テストを味方につけよう 不安を安心に変えよう pytestいいよ！ 書籍もオススメ 35