この記事は カオナビ Advent Calendar 2024 17日目の記事です。
はじめに
カオナビでQCとして働いている赤﨑といいます。
今までテストコードとはほぼ無縁だった私がテストコードの実装に挑戦してみたので、今日はその感想を書こうと思います。テストコードの実装に興味はあるけどまだ試せていない方に読んでほしいです。
BackendのIntegration Testをかじってみた
発端
きっかけはチームのエンジニアとの会話でした。
- エンジニア: テスト設計のアウトプットがあれば、IntegrationTestのテストコードを書いていくとかもできそうだなぁ、一度やってみませんか？
- 私: やりたい！
さっそく1週間後に「チャレンジ会」という名のカレンダーを設定してくれました。
かじらせてもらった
Code With Meのリンクを共有してもらい、同じテストコードを見て説明してもらいながら、テスト設計のアウトプットを参考にここをこう変えて、と手取り足取り教えてもらい、1つだけ失敗するテストを書かせてもらいました。
別の日にまたかじってみた
MRを見ていたら、私が作ったテスト設計に該当するテストコードが見当たらず、どこにあるか聞いてみました。
- 私: このチケットの添付画像の境界値テストってIntegrationTestにありますか？見つけられず
- エンジニア: そうですね、その境界を見てるテストはないですね
- 私: 懸念なければ私書いてもいいですか？
- エンジニア: いいですよ、ペアで作業しましょう！
今回もエンジニアが類似するケースをコピペしてくれて、Code With Meで変更する場所を教えてもらって変更してみました。いじったのはテストデータと期待結果のみで、テスト設計で書いた境界値分析の図の通りに更新するだけです。そしてテストが通るところまで持っていくことができました。以降はエンジニアにバトンタッチしコミットしてもらいました。
味を占めて環境構築した
そして自分でもコミットしてみたいと思うようになり、ENがオンボーディング時に使用していた環境構築手順書の手順に従って環境構築を実施しました。
エンジニアがペアやモブでサポートしてくれる超絶手厚い体制で、環境構築したことがないど素人だけど、テストコードを書ける環境にでき、Code With Meではなく自分の環境でテスト実装して初コミットできました！
テストコードの実装を拾えるようになった
少しテスト設計や手動テストケースの実装が早く終わって、テスト実行待ちができたら、テストコードの実装タスクに着手できるようになってきました。もちろんペアプロしてもらいながらですし、うまくいかないときに独力で解消できないのがもどかしいですが。
かじってみて思ったこと
思ったほど難しくなかった
それはエンジニアによる手厚いサポートがあって、参考にできるテストコードがいっぱいあって、データと期待結果以外いじってないからです。でも今回みたいに臨時でペアプロしてもらいながら実装に入る みたいなことができるという認識を持ててよかったです。
テスト設計の力を改めて実感
テスト設計があればテストコードの実装時にも救われることがわかりました。テスト設計をもとにテストケースに起こすか、テストコードに起こすかの違いだと思いました。
またテストコードの実装のためにテスト設計で工夫するといいことも見えてきました。例えば、境界値分析の図を作ったときに、入力値にアルファベットのアイコンを振っておくと、テストデータのidを図と対応させることができて実装しやすくなったり、MRの概要欄に貼ることでレビューしてもらう時の参考情報になったりもしました。加えて出力結果を一緒に掲載しておくと、実装時に考えることが減ってスムーズでした。
FrontendのIntaractionTestをかじってみた
発端
きっかけはとある振り返り会での会話
- フロントエンドのIntaraction Testで担保してるところまで手動で確かめてるかもという話を話題にしたところ、フロントエンドエンジニアから触ってみないかという話をもらった
- さっそく1週間後に「インタラクションテストを実装してみる会」というカレンダーを設定してくれた
ちょっとだけかじってみた
- お題はプルダウンの選択肢の活性非活性の制御がされていることを確かめるテストの実装
- まずはテスト手順を自然言語で書いてから、自然言語で書いたテスト手順の下にコードを書いていった
かじってみて思ったこと
結構大変
手動で試せばすぐ終わるようなテストなのにこんなに大変なんだと驚きました。もちろんそれは私が慣れてないからでエンジニアが普段実装するときはサクッと終わるみたいです。
手動テストケースの実装と似てるようで少し違う
最初にテスト手順を自然言語で書くというのは、頭を整理しながら進めてとてもありがたかったし、手動テストケースの実装に近い印象でした。ただ微妙に違っていて、手順をちゃんと進められたか、というのも確かめるコードを書く必要があり、信頼できるテストとして維持するための工夫を把握できました。
一方で手順をちゃんと進められたかの確認が入ってくることで、当初IntaractionTestで一番確かめたかったことが後からコードを見たときに見えづらくなる印象を受けました。なので最初に自然言語でテストを書くときに、一番ほしい期待結果が目立つような書き方があるのかもっと聞いたり勉強してみたいと思いました。
2種類のテストコード実装をやってみて思ったこと
とにかくエンジニアには感謝するばかりです、いい会社やなと思います。そしてできることが増えて、すごいことやってる気がする！と沸き立つ気持ちもありました。
ただなんとなく手放しで喜べない気持ちもあり、テストコードを実装できて何がすごいんだっけ？目的は競合に勝って顧客への価値提供を継続することだったけど、それのどこに貢献したんだっけ？技術面の不安の払拭方法が少し増えたかもしれないけど、ビジネス面の不安はあまり減ってないのでは？など、まだモヤモヤしています。
今後の展望
とはいえせっかく身につけた技術なので、境界値や条件分岐のテストは引き続きテストコードで実装してみてもっといろんな学びを得てよくしていきたいと思います。特にテストコードの量について自分なりにしっくりくるラインをイメージできるようになりたいです。
そして、開発面の不安を解消できた先で、手動テストの対象をもっとビジネス面のテストに向けていきたいと思います。
