単体テストの意味でのユニットテストって、別に自動テストサービスでやることじゃなかったりする。
いや、昔は、バージョン管理がしっかりしていなかった頃は、どこが修正されたかわからないから、とにかく全てのユニットテストを実行しないと安心できなかったけど、今は大抵はGitとか使ってるでしょ？で、マスターとか、マージするときにどこを修正したかチェックするでしょ？ 細かい、パーツごとのユニットテストなんて、毎度毎度する意味がない。
修正されてない部分のは。
んなもん、開発中に足場がわりに実行しとけばいいだろ。
ってはなし。
じゃぁ、CircleCIみたいな自動テストで何をテストするか？
マイクロな、各クラスごとのカバレッジ云々のテストなんて、やってもいいけど、それだけやってればOK、ではないよな？(カバレッジ取る用の、専用のブランチでも用意しておけばいいんじゃね？)
それらを組み合わせた、外部に「これこれの機能があります」って約束している、絶対に壊れていないと保証しなきゃならないものがあるでしょ(もし外部から、ユニットテストでテストするような個々の最小単位のクラスをいちいち呼び出させているんなら、モジュール化とかその辺りの意味、もう一度よく考え直せ)。
それは、インターフェイスとか、プロトコルとか呼ばれてたりする。
それが壊れていないことをテストするんだ。
そのモジュールを「使う側」が気にしていることを、「毎度手でテストするのが億劫なテスト」をテストするんだ。
今携わっているプロダクトでは、古いテストが軒並み消されるか、最新形式に書き直されている。
当然じゃないか、と反射的に答えるのはやめて欲しい。
データ移行の必要があって調査したところ、一年以上前に保存されたデータを呼び出すと、例外吐くパターンがいくつかあることが判明した。
詳しいことはこれから調査するんだけど、もう呼び出さない処理があるならテストを消してもいいけど、古いデータも最新の処理で問題ないかチェックするために、生存している古いデータ形式を使ったテストは残しておいて欲しい。
増改築がかなり進んでいて、この辺りを今から整合性を持たせてなんとかしようっての、厳しいかもしれない。
クライアントの要求のたびにアドホックに(て言ったらかっこよく響くけど、この場合は「場当たり的に」とか「その場しのぎに」って意味だから！)修正されてるから、嫌な予感はしてたんだけど。
ここ、なんとかできたとしても、機能も増えないし、時間と金かけただけじゃん、って言われる、下手したら障害発生させたりする可能性もある、とてもとてもとても損な部分だから、やりたくないんだけどなぁ……。
放り出した前任者のツケを、なぜ文句を言われながら自分が払わなきゃならないのか……。
ま、世の中は、理不尽で満ち溢れているからね。
とはいえ、今回の、うまくやり遂げても、なんの箔にもならないんだよねぇ。
今流行りの新しい技術を使って、新しいプロダクトをローンチしました、みたいな。