サーバーサイドエンジニアの小久保(@yhei_hei)です。
本日からクロスマートに関連した技術的なお話を書いていきます。
- 皆さん、テストコード書いてますか？
- 入社当初はAPIのテストコードがなかった
- 慣らしタスクのついでにテストを書きまくった
- 勉強会でAPIのテストの書き方講座をやった
- 皆がテストコードを自主的に書くようになった
- バグを拾ってくれるのはもちろん、レビューしやすくなった
- 理想は全仕様がテストコードで表現されている状態
- クロスマートが気になってきた方はこちら
皆さん、テストコード書いてますか？
突然ですが、小久保はテストコードを書くのが大好きです。
本業はもちろん、個人開発でもテストコードを書いています。
時折、ロジックを書きたくてプログラミングしているのか、テストコードを書きたくてプログラミングしているのか、よくわからない感じになりますw
日々Twitterでテストコード書け書けと啓蒙中です。
↑最近流行のブロックチェーン関連の開発でさえテスト環境を整え始める小久保hardhatを使って、hashlipsのNFTのコントラクトのテストコードを書けたよ。
— わいへい@VLCNP物語ゲーム制作 (@yhei_hei) 2022年8月14日
これでテストネットにデプロイせずともコマンド1発で仕様通りコントラクトが書けているかが確認できる。
以下はmint関数をテストしている模様。#Solidity pic.twitter.com/cXNruFVriY
そんなテスト狂の僕なので、クロスマートの面接も
「テスト書けます！」
「テスト書かせてください！」
の一点張りで入社しました。(超意訳)
入社当初はAPIのテストコードがなかった
で、2022年の1月におっかなビックリ人生初のスタートアップにフルリモートエンジニアとして乗り込んだわけです。
そこでクロスマートのプロダクトコードを見ることになるのですが、
「む？ APIのテストがないぞ？？」
と言うのが第一印象でした。
当時のカバレッジは41%と低め。
重要なバッチにはテストコードが書かれていましたが、APIにはテストコードがありません。
慣らしタスクのついでにテストを書きまくった
入社して1ヶ月くらいは慣らしタスクとして、簡単なAPIの改修を任されてました。
なんとかテストコードを増やしたかった僕は、慣らしタスクのついでに、APIのテストを勝手に書いていったのです。
例えば商品一覧取得のAPIの改修があれば、改修と同時に正常系のテストを書く、みたいな。
どんどん正常系のテストが追加されていき、改修がやりやすくなっていきました。
勉強会でAPIのテストの書き方講座をやった
ただ、1人でテストを書いていても限界があります。
これから改修の入る機能、新規で作られる機能、全てにおいてテストが書かれる必要があります。
チームメンバーの協力が不可欠です。
そこで毎週木曜の10分勉強会で、APIのテストの書き方講座を実施しました。
うちはDjango+Django Rest Framework(以下DRF)を使ってAPIを作ってます。
基本的にJWT認証ありきのAPIのため、テストの書き方にちょっとした癖があります。
あんまりJWT認証つきのテストコードの解説ってないんですよね。。。
その辺りの書き方の基本を解説し、これを真似していけば他のAPIのテストも書けちゃうよみたいな状態に持っていきました。
ちなみにDRF+JWT認証の具体的なテストコードの書き方は小久保のブログにまとめてあります。興味のある方は是非↓
皆がテストコードを自主的に書くようになった
すると、気づけばほぼ全エンジニアがテストコードを自主的に書いてくれるようになりました。
なかには
こんなことを言ってくれる方もおり、 ですよね〜〜〜〜！！！ 僕が言いたかったやつこれなの〜〜〜〜〜〜！！！！！！！ って感じ。
テストコードが加速度的に増えていきました。
バグを拾ってくれるのはもちろん、レビューしやすくなった
Joinした初期の頃はレビューが来ても既存仕様を読み解くのに時間がかかっていました。
が、最近ではテストコードで仕様がある程度読み解けます。
結果、圧倒的にレビューしやすくなりました。
まさに「動くドキュメント」としてテストコードが機能しており、僕の心の中の@t_wadaさんも思わずニッコリ。
もちろん、CI上で動いてバグ検出もしてくれるのでコード修正の負担がかなり減りました。
理想は全仕様がテストコードで表現されている状態
勉強会を終えて数ヶ月。複数人でテストコードを書いて行った結果、
カバレッジは41% → 58%まで上昇しました。
Googleの指標によると60%から許容可能になるとのことで、まだギリダメですw
Google we offer the general guidelines of 60% as “acceptable”, 75% as “commendable” and 90% as “exemplary.” However we like to stay away from broad top-down mandates and encourage every team to select the value that makes sense for their business needs.
Google Testing Blog: Code Coverage Best Practices
とは言え鬼門の50%を超え、体感的にはようやく少し安心して開発ができるようになりました。
また、メンバーからも「仕方なくテストを書いている」というよりは「有用だから書いている」というのがひしひしと伝わってきます。
これがマジで嬉しいです。
そうなんです。テストって便利なんですって。それが伝わればもう本望です。
とは言いつつ、さらなる改善はやっていきます。
次なるゴールは
- 全ての重要な仕様がテストコードに書かれている
- そしてそれが読みやすく、ドキュメントとして機能する
と言ったところでしょうか。
単にカバレッジをあげることを目的とはしません。
例えば3年後。
現メンバーが別プロジェクトに配属されバラバラになり、当初の仕様を誰も知らない状態になったとしても。
残った人がテストコードをもとに仕様を読み解き、99%のデグレはテストコードで検出できる、という状態。
これが理想です。
そのためにはさらにメンテナブルなテストコードの書き方、読みやすいテストコードの書き方をチーム全体で習熟していく必要があります。
やること満載です。
これからも快適なテストライフを送るために、ガンガン啓蒙活動を続けていきます。
時々、具体的なテストコードの書き方も載せていく予定なのでお楽しみに。
クロスマートが気になってきた方はこちら
クロスマートでは絶賛エンジニア募集中です。
このお話を読んでちょっとでも気になった方がいたら
「話を聞きに行きたい」を押してみてください！
