テスト駆動開発の始め方についておべんきょ

テスト駆動開発とか誰がやんねーんって思ってた。

けんか腰でテストファーストであるメリットって何？具体的に教えて？みたいな。

でも要求とかシナリオから設計すっ飛ばして実装に入れる方法を探しててテスト駆動ならそれっぽいことができることを知った。

すっ飛ばしてって表現は間違ってて、詳細にかっちり設計する必要がないくらいのニュアンス。

ふんわり設計で進められるというのは、そこそこの大きさのあるプロダクトだとかなり速度が上がるんじゃないかなーという印象です。

ってことで、知りたいのは、シナリオを得てから開発に入るまでの間をどうすればいいのかということ。

テスト駆動開発から始めるドメイン駆動設計入門 ~値オブジェクト~

まず ユーザーストーリー をもとに仕様を整理します。

シナリオとか要求と呼んでるものをユーザーストーリーと呼ぶみたい。

機能を意味するフィーチャーと似た概念みたいやけど、それやとユースケース？みたいな感じがする。

ユーザーストーリー を作成したらそれをもとに TODO リスト を作成します。

ほいきた。

モデリングとか詳細設計とかすっとばして、TODOリストを作り始めてます。

こっから先はレッドグリーンリファクタリングの話なんかな。

ここまでで。

テスト駆動開発って何だろう

TDDの目指すゴール。いやTDDじゃなくてもエンジニアなら誰もが目指すゴール。 それは「キレイな実装で」で「ちゃんと動く」ソースコードです。

言わずもがなです。

キレイに設計してから/ちゃんと動くところまで持っていく の問題点

「行き過ぎた設計配慮なんじゃないの?」とか「動いたとしてもパフォーマンスが悪いんじゃないの?」とかそういう疑念や実証が始まって、 せっかくキレイに作ったものをまた見直す。

あーたしかに。テスト駆動開発を調べ始めたのがこれですわ。

あとからこの項目が足りない～、あれも足りない～とかで設計見直しみたいなのがつらいからテスト駆動開発を調べ始めた。

「動くからいいじゃないか」という堕落。「動いてるものを触って動かなくなるかも」という怖れ

TDDとは、この堕落や恐怖に打ち勝ち「動く状態」から「キレイで動く状態」に持っていく段階に用いるための開発技法(スキル)なのだということを理解しました。

なーるほ。

動けばいい、変えたくないというのは誰にでもある恐怖。

とはいえ、これを回避するだけならテストファーストである必要はなくない？

それでも「テスト駆動開発」という名前が生み出す誤解がやはりあると、本でも述べられていますし、和田さん自身からも聞きました。 そして生まれたのが「振る舞い駆動開発(Behavior Driven Development = BDD)」なるものです。

これ、振る舞い駆動開発についてもしらべなあかんぱーたんちゃうかなー

レッドグリーンリファクタリングの項は飛ばして

まずはどんなテストが必要かを考えて TODO(やりたいこと/必要なもの)リストを作るところからスタートし、自分の目的地をちゃんと決めておくわけですね

んーむ。いきなりやな。必要なテストをどうやってあぶりだすのかについてはノータッチ？

TODOリスト作りでのポイントは以下になることも理解しました。

・命題を要素に分けてみる

・命題に書かれていない正常系が隠れていないかを見つける

・テスト可能なサイズに落とし込む

・「ただし」のあとは異常系(例外)または準正常系

・優先順位に応じて順序を入れ替える

あーこれか。

命題ってのが要求とかシナリオとか、場合によってはそれを細分化したものでしょう。

要素ってのは続きに書かれてる。

これをまずざっくりと要素に分けると

1〜100までの数をプリントしなさい。

ただし3の倍数では「Fizz」を、

5の倍数では「Buzz」を、

3と5の倍数では「FizzBuzz」をプリントすること

FizzBuzzを要素にわけるとーこうなるみたい。

この後に具体的なのが続くけど、先に共通化とかしちゃってるからそれはリファクタリング先にしてね？って感じがするから無視する。

とりあえず、要求から要素を取り出すのがどういうのを意味してるのか分かった。

それをテスト可能なくらい細分化していって、小さくて重要なのから始めるってことね。

なんとなくTODOリストの作り方を把握したかも。

こっから先は実装についてなのでここまでで。

みんなテスト駆動開発やろうよ

シンプルさこそが TDD において最も重視される価値です。

What (目的) と How (手段) を分離して短いサイクルで繰り返すことで、物事をシンプルに考えられるようになります。

目的と手段の分離っていいな。めっちゃ好き。

しかも短いサイクルでってのも好き。一個のMRが一週間くらいの開発の結果できたものとかやと見てられへん。もっと細かくして―ってなる。

TODOの書き方には要求からTODOリストへの流れがかかれてなかったから飛ばす

そんあとのレッドグリーンリファクタリングも飛ばす

よくある疑問

初期設計はやらない？

ウォーターフォール型開発のような、包括的で完全な初期設計はやりません。

これこれこれこれ。こういうのを求めてた。

進化的設計により、無駄のないシンプルな設計を徐々に導出していきます。

はい、知らん単語。

進化的設計って初めて聞いた。ググり案件。

こっから先の疑問はより実践なことなので飛ばす。

第9回　テスト駆動開発の「サイクル」

タスクやテストリストというもので洗い出しています。

たぶん他の記事で言われてるTODOリストのことやと思う

それらのToDoを，まず簡単に箇条書きにしていくんですね。

直後からToDoって呼ばれるようになってた。

あとはレッドグリーンリファクタリングのお話。

おわりに

いくつかの記事をみたけど、シナリオを細かく割っていって、それをTODOにし、開発を進めていくって感じがした。

進化的設計についてちょっとぐぐったけど、計画的設計に対して実装しながら設計を進めるというスタンスみたい。

それがやりたい！って思ったけど、その論文のなかでは計画的設計も進化的設計もどちらも問題なく進めるのは不可能ということが書かれていた。

それでもやってみないと。

更新履歴