t-wadaさん直伝・TDDワークショップを開催して、社内にテスト文化が芽生え始めた!

こんにちは、バックエンドエンジニアの江間です。

先日、テスト駆動開発(TDD)の日本での第一人者として知られる和田卓人(@t_wada)さんをお招きして、オンラインでテスト駆動開発ワークショップを開催しました。

目次

抱えていた課題感

もともとPR TIMESには自動テストを書いていく文化がありませんでした。2022年初頭あたりから徐々に自動テストを追加するようになって来ましたが、テストを書く経験が浅いメンバーが多く、何となくテストコードを書いている状況でした。

メンバーとしては、テストを書こうとしても、何をテストすればいいのか?どうやって書いていけばいいのか?などが分かっておらず、テストを書くことへのスキル不足が課題となっていました。

また、 PHP のエキスパートとしてジョインしている uzulla さんが「テストの書けるコードがいいコード」と伝えてきましたが、テストの経験が浅いメンバーにとっては「テストの書けるコード」がよくわかっていないという問題もありました。

開催にあたり気をつけた事

社内で自動テストを書いていく文化を作って行きたい、テストを書くスキルを高めて行きたい、と思っていたところ、t-wadaさんによるTDD研修を開催したというブログをいくつか拝見しました。

これは!と思い、早速検討しました。

しかし、当時まだちゃんと自動テストを書く文化が無かったので、ほとんどのメンバーがテストに対するpainを持っていない状態でした。そんな中でTDD研修を受けて、その後の業務で活かせるのか?という懸念がありました。

そのため、本当に受けたい人に限定して受ける事で、開催する運びになりました。

ワークショップ内容

テスト駆動開発ワークショップでは、午前中に事前課題からの続きとして講演+ライブコーディングを受けました。

午後はワークショップを行い、1時間毎にレビューを受けて、最後に全体レビューを受けました。

講演中はslackでわいわい

ワークショップ中は各自がスレッドを作って実況

何人かの方に発表していただき、全体レビュー。

ワークショプを終えて

TDDワークショップの終了後にアンケートを取ったところ、10 段階評価で平均 9.7 という非常に満足度の高い結果になりました。

そして、今回のTDDワークショップが非常に勉強になったとの感想が多くありました。
(以下、アンケートに寄せられた感想の一部抜粋です)

Smallテストの重要性やピラミッドのお話が印象的でした。お話を聞いた限り、PR TIMESのテストの方針がアンチパターン気味なので、理想のピラミッドに近づくようなテストを書いていけたらと思いました。

今回の研修のおかげでテストの書き方やTDDに関する知識が理解できました。
最初は「プログラムの実装前にテストコードを書き」というやり方は私がやっている方と逆なので、初めて試してみるときにちょっと困っています。しかし、コードレビューや1on1してもらうと、このやり方がだんだん慣れています。できれば、他のプロジェクトに応用してみたいと思います。

QAの自動化の話が社内で議論されており、誰かの意見が欲しかったのでとても参考になりました。
また、TDDは名前だけは聞いたことがありましたが、ちゃんとやったことはなかったのでとても勉強になりました。

社内に変化

PR TIMESでは毎週、技術共有定例を行っています。技術共有定例では1週間でやったことや、現在やっていて技術的に悩んでいることの相談等を行っています。

あわせて読みたい
勉強会と技術共有定例という2つの定例ミーティングについて
勉強会と技術共有定例という2つの定例ミーティングについてPR TIMESでCTOをやっている金子 (@catatsuy) です。弊社の開発本部では週1で勉強会と技術共有定例という開発メンバーが集まる2つのミーティングを行っています。これら...

TDDワークショップ以降、さっそく技術共有定例で自動化テストに関するトピックの発表が増えました。そこで挙げられたトピックを共有します。

テストをドキュメントとして扱う取り組み

今まで書かれていた自動テストは、エンジニアにすら伝わりにくいものとなっていました。これではテストのメンテナンスコストが膨れ上がってしまいます。

そのためテストを書く事の次のステップとして、エンジニアやそれ以外にも伝わるテストを書くことを今行っています。

(日本語が母国語の人が多いので)テストの日本語化してテストの理解容易性を向上させたり、そのテスト結果をドキュメント化できるかなどを試しています。

テスト結果のドキュメント化では、QA(Quality Assurance)チームや、PMなどと協力して、伝わるドキュメントとなっているか?仕様の抜け漏れは無いか?などを確認しています。

フロントエンドの unit-test runner を jest から vitest に移行

プロジェクトごとにテストがあったりなかったりしますが、最も新しいフロントエンドコードにはテストが書かれており、 jest で動いていました。 

もともと vitest への移行は zero-config と高速化の観点から行われましたが、ブラウザ UI がありそれを用いることでテストのドキュメント化で活用でき、早速ワークショップで学んだ事を試せる環境になりました。

jest から vitest への移行に関する技術的な詳細は、後日ブログで公開されるかと思います。お楽しみに!

一部の自動テストをGitHub Actions上で動かすための環境構築

自動テストは CI で実行されてこそですが、PR TIMESのメインのリポジトリに追加されていたテストコードは、開発環境がLinuxで動かせない、テストデータのfixtureが未整備などの理由で、CIで実行する環境が整っていませんでした。(各自、ローカルマシンで実行)

TDDワークショップの後、テストをきちんと書く様になって、CIで実行させるモチベーションや必要性が高まってきました。

現在は、開発環境の技術的課題に対して少しずつ改善しており、1つのプロジェクトで GitHub Actions 上で自動テストの実行環境が整備されました。

開発環境や CI の実行環境の整備は今後も改善していく予定です。

終わりに

今回は、t-wadaさんをお招きして、オンラインでテスト駆動開発ワークショップを開催しました。

ワークショップの後、各プロジェクトでテストが書かれ始めていて、ちょっとずつ自動テストを書く文化が出来はじめています。そして、それを実行して、ドキュメントとして活用できるような環境も出来始めています。

このワークショップで学んだ事を業務に活かせていて、非常に良い結果となりました。

PR TIMES ではエンジニア募集中です!

株式会社PR TIMES
02.開発本部 の求人一覧 - 株式会社PR TIMES
02.開発本部 の求人一覧 - 株式会社PR TIMES株式会社PR TIMESが公開している、02.開発本部 の求人一覧です

この記事を書いた人

株式会社PR TIMES 開発本部 バックエンドエンジニア

目次
閉じる