mizzsugar’s blog

Pythonで学んだことや読書録を書きます。

Stapy50回記念で登壇しました

10/9(水)に行われた「みんなのPython勉強会」で登壇した振り返りをします。

startpython.connpass.com

「みんなのPython勉強会」とは、Python初学者からベテランまでいろんな層を対象にしてWebから科学までいろんな題材を扱う「みんな」のための勉強会です。

御縁があってその50回目の会の登壇枠にお誘いいただき、Pythonのunittest.mockモジュールについてお話させていただきました。

speakerdeck.com

ソースコードもまとめました。

https://github.com/mizzsugar/2019_stapy


いいことも改善点もありますが、ちゃんと振り返って精算して次の登壇に活かします!

(※以下、反省文)

登壇前準備

今回は御縁があって登壇のお誘いがあったので承諾してからがスタートです。普段からネタを貯めていた訳ではないのですがぼんやり話したいことはあったしせっかくなのでということで承諾しました。こんな手順で資料を作成しました。

トークの内容とトークの対象となる人を決める

前々からぼんやり「書籍や実践を重ねてテストに関する知見が溜まってきたので1年前の自分に伝えるつもりでいつか話したいな」と思っていました。特にunittest.mockモジュールの使い方に苦戦したので、これについて話そう!と決めました。ただ、話すだけだと焦点が分かりづらい発表になってしまうので「誰にどういう気づきを提供したいか」を詰めました。

結果、「テストコードの基本的な文法(assertEqualとかassertTrueとかレベル)はわかるけれども、unittest.mockモジュールの使いみちがよくわからない人」としました。「こういう時にこうunittest.mockモジュールを使うといい」かのヒントを得ることを目的としました。

トークの目次を作る

特に加筆することはないです。

③ 2で作ったトークの目次が対象の人にとって過不足がないか見直す

最初はunittest.mockモジュールをどういう時に使うかということだけ扱おうとしました。しかし、そもそも単体テストが何を目的として書くのかという話をしてからのほうが何をモックオブジェクトに置き換えるのか考えやすいなと思い、単体テストの例を最初に扱うことにしました。

サンプルコードを何にするかは悩んだので他の人に相談しました。最初に書いたのは軽減税率ではなかったのですが、「この話こそ軽減税率でしょ」という意見をもらい軽減税率にしました。軽減税率は詳しい人からのマサカリが怖かったので一番慎重に何回も書き直しました笑 一番自信がなかった軽減税率の部分は、いろんな人からお褒めいただいたので嬉しかったです。

④ 詳細を詰めながらスライド作り始める。

特に加筆することはないです。

⑤ 15分に収まるか練習

ひたすらストップウォッチと原稿ともに読む練習をしました。読んでいると直したい点が出てくるので読んでスライド手直して読んで・・・を繰り返しました。

また、人に聞いてもらって間違えた伝え方や誤解を生みやすい言い回しを修正しました。協力してくれた人には感謝しかありません。ありがとうございます。

登壇本番

ブラウザのトラブル

Googleスライドで原稿とストップウォッチを見ながら読む練習をしていたのですが、途中でブラウザの再読込をしないと次のスライドが映らないというトラブルに見舞われました。急いでスライドをspeakerdeckに変えたのですが、原稿とストップウォッチが見れないのと焦りの気持ちで15分オーバーしてしまいました・・・

原因は定かではないのですが、firefoxGoogle slideいじってておかしくなったかもしれない説が自分の中で有力です。Chrome試してみた時はなんともなかったので。次からはChromeで発表しようと思います。(※ちゃんと原因特定できていないのでもしかしたらfirefoxは何も悪くない可能性があります)

質疑応答

slidoという質疑応答アプリに匿名の質問が集まっていたので回答したのですが、匿名が故の難しさを感じました。というのも、2-3分の質疑応答で一方的な答えをちょちょっと言っただけでは質問者を納得させることが難しいような質問があったからです笑 

「モックとはなんですか」という極めて抽象的な質問をいただきました。抽象的な概念についての質問は質問者のレベル感を把握した上で、どこがどう疑問なのか対話を通して理解してもらうのが望ましいですが、それを考慮せず一方的に自分が思う答えをただ言ってしまったのが反省点です。

プログラミングを初めて1ヶ月の人が質問したとして、どう答えても理解は難しかったと思うので、「今回わからないのはどうあがいても仕方ないので、勉強を進めてテストコードをより良くしたい段階になった時にこの資料を見返して、その時にわからなかったらDMなりメールなりしてください」と答えるのが良かったかも、と今は思います。その場でわかってもらうことだけが正しいわけではないかもしれません。

初学者もいるコミュニティでの題材は初学者にも理解できる題材にすべきか

SNSやslido(質疑応答用アプリ)を見ると、「余計に混乱した」「結局モックがわからなかった」という声がありました。「発表を聞いてわからなくなった」という声がある場に居合わせたことがなかったので、「表立って言いたくなるほどわからなくなるようなだめな発表だったのかな」とショックを受けました。

15分の制約があったので、申し訳ないけれども、全くのプログラミング初学者はこのトークの対象から外す選択をしました。

やっぱ選択間違えたかなと思ったのですが、後々に

「誰もが楽しめる発表はないので対象を絞ったほうが良い内容になる」というアドバイスや「全く発表がわからなかったけれども発表を聞いてunitttest.mockを勉強したいと思いました」という感想をいただいたので、

内容はもっとブラッシュアップしつつ方向性はこの方針で行こうと決めました。

もしこのトークでもう1回登壇するならば

  • とはいえ「モック」の概念の説明が不足していたのでモックの概念をもう少ししっかり説明する

  • 本題に入る前に予めこの発表の対象となる人を伝えておく

  • 「モック」と「スタブ」の概念も扱って、どんな観点で単体テストを書くかをより深く扱う

  • 対話を通してでないと理解が難しいであろう質問は2-3分の質疑応答の時間で理解されなくても落ち込まない。交流会とかで詳しく話そうねというスタンスで挑む。

  • Chromeで登壇する

で行こうと思います。

登壇に誘って下さった方、聞いてくださった方、フォローしてくださった方、準備に協力してくれた方、ありがとうございました。