ユニットテストのお話。あるいは仕事中の考え。

さーて、ようやくプロジェクトが動き始めたって感じだな。要件がふわっとし過ぎて、こりゃ僕が要件定義から始めないといけないかな？　と思っていたけどディレクターさんがまとめてくれた感じ。僕は所詮、下流工程の技術屋なんでディレクターとかまとめ役のSEとか居ると安心する。交渉が苦手なんで、要望を全部断れずにいつも苦労していた。このままだと一人アジャイルに突入するなと危惧していた。

扱ってるCMSのコードもなんとか全体像がつかめてきた。あまりにもレガシー過ぎて処理が全く追えないって感じだったけど、スプラウトメソッドで処理を分離させていたら使い物になる程度には整理できた。『レガシーコード改善ガイド』は良い。レガシーコードと戦うプログラマの心構えが全部書かれている感じ。どうにもならなくなった時の考え方も書かれている。

レバレッジメモ: レガシーコード改善ガイド - 西尾泰和のはてなダイアリーレガシーコード := テストがないコードテストを作成するためには対象とするクラスから他のクラスへの影響を把握する必要がある。依存関係を排除しておけばニセのクラスを突っ込んで影響を直接観察できる。テストをするたびに本番コードを編集するわけには行かない、なのでコードを編集せずにテストに不都合な挙動を変えられる場所が必要である。これをseamという。どのseamも、その挙動を変更するenabling pointを持っている。日本語で「接合部」っていうとくっつけることに意識が向きがちだけど「そこで切り離せる」というほうが重要なのだな。 既存のレガシーコードに機能追加をする方法 1: スプラウトメソッド…d.hatena.ne.jp

心残りとしてはPHPUnitでテストコードも書いてるけど、テスト環境依存のコードなんだよね。Model部分とか全然読めていないから、モックが全然できていない。jenkinsが設置されているから、カバレッジを見ながらニヤニヤしてやろうかと思っていたけど、それは当分先の話だろう。

プログラミング周辺だと、これが気になった。

qiita.com

逆説的だけどある意味正しいよなと思った。だけどテストは先に書いた方がいい。即座に動作を確認できるので、実装の体感速度が違う。コーディングで小さなサイクルを起こすというのはプログラマのライフハックとして重要。自分はユニットテストの要望が無いときでもテストコードを書く。結果的にそれが早いからだ。

ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 - Qiita最近、あまりプログラミングが得意でない人のサポートをする形で、長い時間にわたってペアプログラミングを行っている。そのなかで、気がついた悪い習慣と成長するための良い習慣というものをまとめてみる。 この記事のバックグラウンドとなる体系的知識が本になりました。 エンジニアリン...qiita.com

後はスケジュールとの睨めっこだな。