SI的なプロジェクトに自動テストを導入してもうまくいかなかった話

f:id:kitahashi-ryoichi:20150731103325j:plain

PHPunitを導入してみた!

フルスクラッチの基幹システム刷新とかそういうプロジェクトにパッケージ開発の勢いでPHPUnitテストを強制にしてみた。

 

その目的

目的としてはデグレを検知できるようにすること。

テストコードを書く時に不具合を開発者が見つけるようにすること。

この2点のためにPHPUnitを開発者に書かせました。

 

 

起きた問題

・そもそも単体テストの書き方を知らない

 →setUp,beforeClass,tearDown,afterClassの使い方もわからない

・プロダクトコードが長すぎてケースが爆発する

・テストにロジックを書き始める

・Jenkinsのエラーレポートを無視して0件に中々ならない

・テストを書くと設計がシンプルになるという幻想

 →テストを書いてリファクタするにはちょっとしたスキルがいるみたい

 

基幹系のSEって単体テスト書かないの!?

 

どうやったらこの問題を回避できたのか・・・

 

そもそも単体テストの書き方を知らない

何も知らないことを前提として、サンプルコードで具体的にこういう風に実装するというのを教えないとダメ。世の中の大多数はまだユニットテストを書き慣れていないという事実。まだSIの世界ではスクリーンショットをExcelに貼り付けるエビデンスをとっている。

 

プロダクトコードが長すぎてケースが爆発する

テスト駆動開発でリファクタしながらシンプルな設計を維持するというのは慣れていない人には面倒くさいらしい。実際にライブコーディングをして簡単さをアピールした方が良かったかもしれない。トータルで見ればコードを分割した方が楽になるはず。

 

テストにロジックを書き始める

テストにロジックを書くとそのロジックをテストするのはだれだ?問題。結構衝撃的なコードだったが、とにかくテストして終わらせようとする姿勢だけ感じ取れる。

 

Jenkinsのエラーレポートを無視する

そもそもJenkinsを見るのが始めて。教えてあげないと人は見ようともしないし、それがどんな有益かを見せないとダメでした。成果が可視化できるっていいよね。

 

テストを書くと設計がシンプルになるという幻想

見せるしかない。言っても何も響かないしよくわからない。

 

まとめ

結局自動テストを導入するとものすごい便利なのに、その便利さを体感したことがない人にはよくわからない。ライブコーディングなどで便利さを見せたりプッシュが必要だったと振り返って思う。あと普通のエンジニアの能力は過信しない方が良い。テストすら書いたことがない人はたくさんいるということ。