TDDで1年間開発してきた私が改めてTDDについてまとめていこうと思う。
こんにちは。読んでいただきありがとうございます。
最近改めてTDDに関して考える機会を得たので、ブログにアウトプットしていきたいと思います。
私はエンジニア歴1年1ヶ月でずっとTDDで開発してきたのですが、今更ながらTDDもどきであることにこの度気付かされたのでそれについても最後にまとめます。
本日のアジェンダは以下です
- TDDとは
- TDDの開発手順
- TDDのメリット
- TDDのデメリット
- 私の関わってきたTDD
①TDDとは
TDD(Test Driven Development)とはその名の通り、テストファーストな開発手法になります。「仕様を決めて実装してテストする」というのが一般的な開発手法かもしれませんが、TDDでは「仕様を決めてテスト仕様書を書いてそれを元に実装する。」という流れで開発していきます。
私は受託開発でレガシーな開発をしておりますが、アジャイルのモダンな企業においてもTDDを取り入れられている所もあるそうです。(最近知りました。)
②TDDの開発手順
改めてTDDの開発手順についてまとめていきます
手順1.レッド
TDDの肝とも言える、テストコードを記載することです。仕様を満たすテストコードを書いて実行するため、最初はエラーしか出てきません。それからレッドと呼ばれるようになったみたいです。ここが一番重要だったりします。
手順2.グリーン
レッドだらけのテストコードがグリーン、つまりエラーが出なくなるようにソースを書いていく段階をグリーンと呼びます。ここでは、エラーを無くすことと動くコードを書くことが大事です。
手順3:リファクタリング
最後にリファクタリングをかけて完了となります。
③TDDのメリット
1.後工程へバグを持ち越しにくい
テストコードさえ間違っていなければバグを生みづらく、後工程にも影響が出づらいです。これが一番のメリットではないかと私も実感しております。
2.システムの要件をより深く理解できる
テストコードを書く際は、システムの要件を理解することが前提となります。要件を細分化してリストアップして作成していくので、システムの要件をより深く理解できます。
④TDDのデメリット
1.開発時間がかかってしまいがち。
どうしてもコーディングの時間が長くなるため開発に時間がかかってしまう可能性があリマス。
2.仕様が変わるごとにテストも書き換える必要がある。
開発を重ねただけテストコードも増えていきます。その結果仕様を変更したいとなった際、昔書いたテストコードの書き換えの作業も発生する可能性があり、開発スピードに影響する可能性があります。
⑤私の関わってきたTDD
私はTDDで開発してきたものの、一度もテストコードを書いたことがありません(レガシーですね)。工程としては先程紹介したやり方ですが、テストコードなしのTDDなのでTDDの良さを最大限発揮できていない開発を行っています。
テストコードを書かない理由は、仕様変更の頻度が多いことにあります。テストコードを書くと変更が莫大になってしまい、もっと開発スピードが遅れてしまうのが原因です。
個人的には、テストコードをたくさん書いて保守性の高いコードにしたいのですが、、こればかりは私にはどうしようもないです。
テストコードを書くのが当たり前の世の中ですから、私も早くテストコードを書く経験を積んでいきたいものです。。。
今回は以上になります。
最後は少し愚痴っぽい話になってしまいましたが、でも自身のやりたいことを尊重してくれて挑戦させてくれる企業で私は働けるよう、日々精進してまいります。
転職活動も難航の色が見えますが、挫けず頑張ります。
最後まで読んで頂きありがとうございました。