7
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

自動テストを充実させるためにやったこと

Last updated at Posted at 2023-12-22

こちらにも載せています

こんにちは。
パンダ好きエンジニアの @pandineer です。

本記事では、自動テストを社内で広げていくために行ったいくつかの取り組みを紹介します。

自動テストを充実させたい、その背景

atama plusでは「教育に、人に、社会に、次の可能性を。」というMissionの実現のために、不確実性に向き合いながら事業やプロダクトを成長させています。
これからも、不確実性に向き合いながら事業やプロダクトを成長させていくためには、変化に強くなる必要があります。
開発者目線でも変化に強くなるための打ち手はいくつもあります。その中の一つとして、変更容易性を高く保つために自動テストを充実させたい、という想いがありました。

自動テストを充実させるために取り組んだこと

自動テストを充実させるために、色々な取り組みを行ってきました。今回は、その中でも特に私自身が深く関わった「テストギルド・パーティの設立」と「lumberjack day(社内ハッカソン)」の取り組みについて紹介します。

テストギルド・パーティの設立

atama plusでは、フィーチャーチームとは別に、特定技術領域の横断組織体として「ギルド」、その分科会的位置づけとして「パーティ」という制度があります。
現在、テストコードに関連するものとして、「自動テスト推進ギルド」と、各テストフレームワーク/ライブラリごとに、「Jestパーティ」「pytestパーティ」「Playwrightパーティ」が活動しています。
ギルド・パーティについては、Advent Calendar20日目のigawyさんの記事でも詳しく説明されています。

自動テスト推進ギルド、および各パーティでは、テストコードを拡充することそのものよりも、みんなが拡充しやすくするための活動をすることが多いです。使い方を紹介したり、テストコード実装方針を考えたり、みんなのお困りごとの相談に乗ったり、という活動をしています。

例えば、Jestパーティでは、以下の目次を持つようなドキュメントを作成して、テストコード実装の一歩目が踏み出しやすくなるようにしています。

スクリーンショット 2023-12-21 11.10.59.png

テストコードを書く目的に関しては、柴田 芳樹さんがJaSST'18 Tokyoで講演された際の資料「私が経験したソフトウェアテストの変遷」を一部抜粋して利用させていただきました。
https://www.jasst.jp/symposium/jasst18tokyo/report.html

基本的な使い方をまとめるだけではなく、社内のお困りごととその解決策や、細かいテクニック、参考になりそうなPRなど、テストコード実装の応用編と言えるようなナレッジも貯めるようにしています。それにより、各開発メンバーが迷いなく、自発的にテストコードを充実させていけるような仕組みづくりに取り組んでいます。

Jestパーティでは、他にもflakyなテストを見つけて修正したり、テストの実行速度の改善に取り組んだりしており、テストコードのさらなる拡充へ向けて着実に貢献できていると思います。

lumberjack day(社内ハッカソン)

atama plusでは、社内ハッカソンとして「lumberjack day」を開催しています。
ハッカソンについては、詳しくはこちらの記事を御覧ください。

先日のハッカソンが開催された際、ちょうど世の中を沸かしていたGitHub Copilotが社内でも使えるようになったタイミングだったため、私と上述のigawyさんが、「GitHub CopilotやGitHub Copilot Chatを活用してテストコードを効率的に書くプラクティスを探る」というテーマで参加しました。

ハッカソンでは、ツールを利用するまでの流れを確認した後、どうしたら良いテストコードを生成できるかについて試行錯誤しました。

成果発表では、他のエンジニアにもハードル低く利用してもらいたかったので、

  • インストール〜利用するまでの流れ
  • おすすめのプロンプトと合わせて、実際にテストコードを生成する様子
  • テストコードを生成してからマージできるようにするまでのプラクティス

を、スクショ付きで丁寧に紹介しました。

ハッカソンで実際にやってみて、以下の感触を得ました。

  • シンプルなコンポーネントだったらそのままpassするテストをつくれそう
  • 複雑なコンポーネントの場合は、プロンプトを色々試したり、プロンプトはそのままで再生成を何度か試すことで良いテストコードが得られそう

いずれにせよ、テストコードを書くためのとっかかりを作るには十分良さそうで、書き始めるための心理的ハードルは下げられそうです。

以下は、実際にCopilotを利用したエンジニアの社内のつぶやきです

スクリーンショット 2023-12-20 21.57.01.png

これまでとこれから

本記事では、自動テストを充実させるために取り組んだことの内、ギルド・パーティの取り組みと、社内ハッカソンの事例を紹介しました。
これらの取り組みも実を結び、テストコードは着実に増えてきていますし、お困りごとのレベル(難易度)も上がってきていると思います。

一方で、Advent Calendar16日目のsekkenさんの記事や、Advent Calendar20日目のigawyさんの記事でも触れられている通り、(高ければ良いというものでもありませんが)カバレッジもまだまだ上げていきたいですし、今はまだテストコードをどんどん書いていこうというフェーズのためテスト戦略を考える段階には至っていません。

これからも、新しいナレッジやツールを適宜取り入れながら、着実に前に進んでいきたいです。

明日は@seigai_tk24さんによる「第三者検証からatama plusのQAエンジニアに転職してみて」です。
ぜひ御覧ください!

7
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
7
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?