【BDD, TDD】テストコードを書いていて感じたこと その1
こんにちは、日に日に寒くなってきましたね。
ふと思えば本日は11/28で今年も残すところあと１ヶ月になります。
このブログでは「ドラムと筋肉とプログラミング」ということで、それぞれについて思うことを発信して行こうと思ってたのですが、気づけば「プログラミング」の記事がメインとなりつつあります。。。
とはいえ、筋トレは自作アプリにより自重トレーニングが継続できるようになりましたし（自分の胸筋好きになった！）、ドラムも昨年よりスキルが上がったと思います。
今年も残り限られてますが、自分の体に労わりつつ、新たな気付きを得られるよう行動していきたい、そんなふうに感じた今日この頃です。
はじめに
さて、ということで相変わらず？プログラミングのお話です。
前回の記事でBDD, TDDについて触れ、テストコードを書き始める前に自分のソースで気づいた点をまとめました。
BDD, TDDを始めたいです・・・ - ドラムと筋肉とプログラミング
「内部の振る舞いが理解できていない」という現状があったので、現在「仕様」に対する振る舞いも整理していて、その上でテストコードを追加しております。
この作業をする上で、改めてインターフェースを先に実装していくと言った考えが特に重要だなと感じた次第です。
本日の記事では、新たに機能を追加する際に、インターフェース（プロトコル）から実装していく必要があると思いますが、どう言った観点で実装していくべきかまとめようと思います。
→ぶっちゃけ前回の記事の言い方変えただけ！でもありますが笑
結論
新しい機能（仕様）を追加する際に、以下に関するインターフェースから検討・実装する
例
整備中・・・
理由
インターフェースから実装するということは、「仕様の骨子を設計する」と言い換えることもできると考えています。
この骨子を設計することは、プログラムの「全体像」が見えるタイミングでもあるため、この時点でメソッドに対する実装は絶対にしてはなりません！！
私は欲しい機能に対して全体の骨子の実装から始めていなく、基本的に正常系のケースしか考慮していませんでした。
後に異常系も検討して行こうと思っても、正常系にのみ対応した構造になってしまっているため、再度「骨子（インターフェース）から見直さないといけない状況」になっていました。
家を建てるという建築の話に例えると、家の骨子（柱）から作り始めずに壁の塗装や階段を実装し始めてしまったので、後で思う位置に部屋を追加できなくなってしまう、って感じでしょうか（適当）。
プログラムは家と違ってやり直しが効くので、後から骨子を見直すこともできますがそれだけ時間が必要になってしまって無駄です。
ついでに思ったこと - シーケンス図ってやっぱ大事だよね
振る舞いを明確にするために同時に「シーケンス図」があると超いいな！と感じた次第です。
最近アジャイル開発などで設計書はいらん！みたいな話がありますが、私はこのシーケンス図は絶対にあったほうが良いと考えてます。
特に、仕様が多岐のクラスに跨いで振舞うことで、コードを追いかけるのが面倒くさくなります。
→私はアジャイル開発したことないので現状はよくわかってないですが・・・
こう言ったときに、どんなクラスに影響するのか？一つの図で表現できると振る舞いに対する理解が圧倒的に早くなると思います。
自分はシーケンスまで作れてないのですが（さぼっていて）、シーケンスを自動化できるツールがあったら是非導入したいです。
ちょいとググってみますか・・・！
最後に
言い訳ですが、概念に対して「例」をすぐに出すのって難しいです・・・
自分の考えをまとめる(発進する)機会を増やして、こう言った例題もパッと出せるようにしたいです。
