この記事はTDD Advent Calendar jp: 2012の14日目の記事です。前日はposaunehmさんのJUnit実践入門 MSTest用パッチ #TddAdventJpでした。 プログラマであれば、多かれ少なかれシェルスクリプトを書いた経験はあると思います。でも、シェルスクリプトでユニットテストを書いたことのある人は意外に少ないのではないでしょうか。 シェルスクリプトでユニットテストを書くには? shunit2 を使います。ダウンロードして解凍してexamplesの下にあるシェルを実行すればサンプルが動きます。 $ sh ./equality_test.sh testEquality Ran 1 test. OK 使い方 test で始まるファンクションがテスト対象になります。また、テストスクリプトの最後でshunit2を読み込む必要があります。
TDDBCのUstを見てから、テスト駆動開発についてちゃんと勉強しようと、テスト駆動開発入門とレガシーコード改善ガイドを読み始めました。 ほとんどの開発現場がそうであるように、うちの開発現場でもレガシーコードで溢れているのですが、レガシーコードとは一体なんなのでしょう。レガシーは「遺産」という意味なので、技術的負債と考えればよさそうです。では、どのようなコードが技術的負債なのでしょうか。 テストがないコードはレガシーコードだ! レガシーコード改善ガイドに以下のような文章がありました。 テストのないコードは悪いコードである。どれだけうまく書かれているかは関係ない。どれだけ美しいか、オブジェクト指向か、きちんとカプセル化されているかは関係ない。テストがあれば、検証しながらコードの動きを素早く変更することができる。テストがなければコードが良くなっているのか悪くなっているのかが本当にはわからない。 ここで言うテストとは、テストコードのことを指しています。なぜテストコードがないとレガシーコードなのか、コードがきれいで拡張性が高いだけではなぜ不十分なのか。 新規のプロジェクトが立ったとき、ほとんどのエンジニアは美しいコードを書きたいと思っているはずです。コードがきれいで拡張性が高く、将来の仕様変更や機能追加にも柔軟に対応できるようなコードです。
TDDBC in TokyoにUst参戦してきました。(と言っても録画でですが…) ATNDに登録されてから一瞬で参加枠が埋まり、競争率300%overのこちらのイベントでしたが、Ustで配信して頂いたお陰でサテライトながら参加することが出来ました。すごくタメになる内容だったのでエンジニアの人は絶対に見るべき。こちらに動画が上がってます。 というわけで、自分のためにUstの内容をまとめます。ブログに書かないと覚えておけないので。。内容が濃く、いっぺんに処理しきれないので、今回は@t_wadaさんの基調講演に絞ってまとめます。LTはまた別途。。 TDDBC基調講演内容まとめ 現代ソフトウェア開発の三本柱 バージョン管理 バージョン管理システムをつかいこなして、ソフトウェア開発の歴史を自信を持って管理していく。 ソフトウェア開発においてバージョン管理がないと死亡確定。 テスティング 自動でテストを行うテストコードを書きながら開発を行う。 TDDBCで講演するのはこの部分。 自動化 jenkins,