テスト駆動開発による組み込みプログラミングをやってみる Vol.0
オライリージャパンから出版されている本。ずっとやってみたかったんだけど、ただ読んでるだけになってた本。
ようやくやれそうなので、少しずつやってみる。
あと、書かないとやらないので、ここでやってることを残しておこうｗ
『テスト駆動開発による組み込みプログラミング C言語とオブジェクト指向で学ぶアジャイルな設計』
James W.Grenning 著
蛸島 昭之 監訳
笹井 崇司 訳
これによると、組込み環境をかなり意識した本になっています。
私も自分でユニットテストフレームワークもどきを作ってやってみたことはありますが、横展開するにはちょっとちゃち過ぎましたので、これを機に正式にフレームワークとしてリリースされている成果物を利用させていただこうと考えています。
(商用品は高いし、会社は買ってくれないしねｗ)
1章 テスト駆動開発
さて、1章からやっていきます。
1章では、「テスト駆動開発とはなんぞや」ってところを、洋書にありがちな非常に気さくな感じの文書体、ジョークなども交えながら教えてくれます。
ここでは「なぜTDDが必要か？」が説かれています。
※テスト駆動開発を英語で書くと Test Driven Development=TDD ですね。
基本的には次のようなことが言われていると理解しました。
本の内容を丸々コピーみたいになるからこれ以上細かく書けないけれど、大体こんな感じですｗ
- テストしないとバグが入り込む隙を与える
- レビューでは気付かないかもしれないが、実際にコードを動かして(=テストを実行して)みれば気付ける
- バグの混入が疑われる箇所には全てテストを書く必要がある
- テストを書こう！
- TDDは「レッド～グリーン～リファクタリング」という小さなサイクルを高速で回す
うん、そうですよね。ずっとうなずいてました、読みながら。
会社でもよくあるんですが「単体テストは書いてない」「単体テスト仕様書はあるけど、それを実施するのは一度だけ」とかっていう状況に出くわします。非常によく。
一度きりの仕事なら確かにそれもいいかもしれません。
でも、その仕事が本当に一度きりかどうかなんて「その時」が来ないとわからない訳です。
それに、エンジニアの端くれとして、「動くかどうかわからんもの」を堂々とリリースする気にはなれません。
「じゃあやっぱりちゃんとしないとまずくない？」と思うのですよね、自然に。
それに、この考え方を知って私はこう感じたのです。
「自動化された実行可能なユニットテストはコードを保護するツールだ！」と。
これって、受託開発とかでも使える考え方なんじゃないかと思っているので、是非会得して実践したいですね＾＾
そして、その後この考え方が既に体系的に纏められていることを知り、勘ではなく確信に変わったのですが、それはまた別のお話。
『レガシーコード改善ガイド 保守開発のためのリファクタリング』
マイケル・C・フェザーズ 著
ウルシステムズ株式会社 監訳
平澤章／越智典子／稲葉信之／田村友彦／小堀真義 訳
そんなこんなで、まずは1章(P.1-P.10)読破！
2章から実際にやってみることになるので、その前に環境構築からやっていきますかねー。
恐らく、環境は Codeanywhere + DevboxでLinux(UbuntuかCentOS)になりますんで、その辺りのことも触れながら書いていきます。
最終更新：2014年12月09日 23:38
