ほげほげ見聞録

技術メモ、備忘録、使い方はそのうち覚える

TDDを始めて~CI環境構築の振り返りメモ


タイトルのとおり振り返りメモ、ポエムともいう。…てか、どう見てもポエムです。
主に今年にやっていた自動テストとCI環境構築について感じた事考えた事をダラダラっと書いていく。

自動テスト・TDD・リファクタリング

「自動テスト」という単語を知るまで

哀しいかな、自分が属している会社では自動テストを書くという習慣はなく、当然ながら存在を知る機会はなかった。
ぼちぼち仕事にも慣れてきた頃に、オブジェクト指向を勉強しなおしたりデザインパターンに出会ったりした。
その時ようやく、会社のコードはレガシーで「テスト」はブラウザチェックだけだな…という漠然とした印象を抱いた。
といっても、その時は話しやすい先輩に「何だかレガシーですよね」と愚痴る程度だったが。別に自分がレガシーじゃないコードを書けているかというとそうでもないので以下略。

その後、長期的なプロジェクトに参加・続ける内に、コードを改修する事が増えてきた。
必要だと思って「リファクタリング」「レガシーソフトウェア改善ガイド」等をざっくり読んでみたが、どちらとも「テストを書け」とあった。しかも自動化。
自動でやると言えばSeleniumくらいしか知らなかったので、そんなものがあったのかと軽く驚き。
調べてみて「テスト書くのは当たり前」などの情報に遭遇してカルチャーショックを受けた。
調べても必要性と導入方法が分からなかったり、振られたタスクで忙しかったり、諸々に嫌気がさしてソシャゲに時間を費やしてしまったり…等の事情でその時は調べるだけに終わった。

テスト駆動開発」の新訳版が出た

プロジェクトも落ち着いてはきたが、何かうまくいっていないという思いがあったので読んでみた。
詳しくは以下の記事。
dwmemo.hatenablog.com

TDD続けてみてどうなったか

上の記事から数カ月経ったわけだが、新規案件では必ずテストを書くように習慣付いた。
改修だと余計なファイルを追加してはいけない場合、そもそも自前のフレームワークでテストを書けない場合もあった。
余計なファイルを追加できない場合は、グローバルインストールしたPHPUnitからテストを実行し、テストファイルと関連の設定ファイルをGitと並行して使っているVCSで管理するという感じで対応した。

簡単な処理はテスト書かずに実装したり、難しそうで関連部分でリファクタリングが必要な場合はテストを書いたりと、緩くやるのが自分には合っているようだ。

必ず失敗はある

自動テスト及びTDDに詳しい人がいれば教えを乞いながら進めるが、本だけだと完全に手探りだ。
テストして問題なかったと思ったら、実はテストが間違っていたなんて事は最初の内は特に多いと思う。
可能ならチーム内で確認する機会を設ける、失敗が許容されやすいプロジェクトでやる、等の予防線を張っておきたい。

カバレッジ

カバレッジは気にしない方が良いという話も聞いた。
数字が出てしまう以上、完璧にしたい欲求や要望が出るのはしょうがないとも思う。
こういう時は「どうしてテストするのか」原点に戻って考え直したい。

また、テストが書かれていない部分を修正する時も無理に全部のテストを書かなくても良いと思った。
例えば、ある関数の一部分を修正する際に、修正部分以外の簡単な部分までテストを書く必要性は低いという事だ。その部分は既に別の方法でテスト済だろうから。
ただし、修正部分に影響されたりロジックが難しかったりする場合は、折角だし追加で書いた方が良いと思う。

CI環境構築

自動テストを書くようになってから、CI環境構築しろという指令があった。
構築している間にPHPerKaigiに行く機会があって、色々な人の話を聞けたのは大きかった。
dwmemo.hatenablog.com

あんな事こんな事あったでしょ

ブランチをプッシュするとテスト環境にデプロイ・テスト実行できるようにJenkinsおじさんに頑張ってもらった。
dwmemo.hatenablog.com

とっても気を付けたい事

一番、大事なのは、公式ドキュメント。
グーグル先生の検索結果の上位に出てきた個人のテキトーな解説ブログではない。

特にひどかったのがCSRFのチェックでJenkinsのジョブを実行できない件について。ろくな解説なしに、「CSRFのチェックを外せば解決」という一文程度の記事が出てくる。
大事なのは、どうしてそんな設定があるのか、その設定は変更しても良いのか、変えずに処理を行う方法はないのか、考察する事なんではないかと思った(自戒を込めて)。

構築して分かった事

CIは多少時間が掛かっても・余計な操作があったとしても「確実に」実行するものが良い。

今回はプッシュされたブランチを判断するのにNodeJSを挟んでみた。
しかし、見事にその部分でエラーを起こしCIが回らなくなってしまった。
特にNodeJSの部分はエラーが出ても分からない(通知が来ない)という問題点があった。
結局、NodeJSの部分は省いて時間は掛かるがブランチがプッシュされる度にデプロイする方式が選ばれた。

エラーがすぐに分かる事、エラーをすぐに直せる事、そもそもエラーを発生させない事…が特に重要だと思う。

CIに限らずプロジェクトのコードは全てそうあるべき、と言われてしまうと御尤もとしか言えないが…。
記憶容量を割く必要がないのは断然CIの方なので、特に気を付けるべきかなと思う次第だ。

ドキュメント

完成すると「はい、終わり」にしてしまわずに、もしもこの環境を自分以外の人がいじるとしたら…という考えを持ってドキュメントを残しておくべきだ。
頑張った事でも案外すぐに忘れる。

最低限、処理の流れと使っているものについては残しておきたい。
本当だったら社内ウィキ等に試行錯誤の経過を残しておいた方が良いと思われる。
自分の場合は社内ウィキを使う人がほぼ皆無だったので個人ブログのネタにしてしまったが。

テストはCIに組み込むべき

誰もが自動テストを書いて手元でテストスイート実行してくれるなら問題ないんだけどね。
それでも、テストに不慣れなチームだとA環境ではエラーなし、B環境ではエラー発生なんて事が起こりうる。
どの環境でも実行できてエラーの起きないテストを書き、それを自動的に確認するという手順を踏むと不安は減るかなと思う。

最初は組み込む予定なかったのに、途中からCIに入れるとなるとテストの手直しがかなり面倒になる。これは本当に、もう面倒…。


まとめ

自動テストを書き始めてから大体三、四ヶ月で、ようやく必要性や実用性が分かって来た。
また、チームや組織にテストを書く文化を広めるのは一人でやるのは無理なのが良く分かった。自動テストを書く・TDDは個人スキルと割り切ってしまうのが楽。
何をするにも権限が必要だし、権限を貰ったからには責任が付いて回る。
自動テストを強要する権限があったとして、メンバーの残業時間増やせるのか・工数増やせるのかとかそういう問題になってくる。それはプログラマの問題ではなくマネージメントの問題だ。
ここら辺はチームや会社によっても変わるんだろうけど。

CI環境構築ではネットワーク部の主と直接やり取りができて良かった。
普段一緒に仕事しない人の話を聞けるのは勉強にもなるし。
英語苦手なので、公式ドキュメントをヒーヒー言いながら読むのも、まぁ勉強に…なったかな。

TDDにしろCIにしろ、まだまだ勉強不足なので気長に付き合っていこうと思う。