雑に作って、それから作り込んで、最後にテストを書く「テストラスト」開発 - give IT a try

（この話は最初Twitterに書こうと思ったけど、長くなるのでブログに書くことにしました） 僕はRSpecやMinitestでテストを書くのは得意ですが、常にテストファースト（TDD）で開発するとは限りません。 今業務でやってるタスクはこんなふうに進めてます。 雑に動くものを作る ↓ 見た目をきれいにする＆機能を作り込む ↓ テストを書く ↓ リファクタリングする この順番で開発する理由を以下に述べます。 雑に動くものを最初に作る理由 最初は見た目とか、異常系とか、細かい仕様とかを無視して、正常系が一通り動くものを作ります。 これはこれから作ろうとしているものの認識が合っているかどうかをPO（プロダクトオーナー）に確認するためです。 実際に動く画面を見せると「こんな感じでOK」とか「ここはこういうふうにしたい」というフィードバックをもらうことができます。 また、開発者としてもコードを書きな

[brn_take]

そもそもスタートアップや市場の反応がわからないモノを作るときはテストなんて後回しでいいやろ スピードが全てで当たったら作り直しゃええ プロダクトのフェーズが全て

[gabill]

一番不確実なレイヤーのテストを最初にやろう、ということか。

[t-wada]

仕様が固まることはないので、テストが得意な人やテストを書きやすい領域では粗く雑なテストを同時に書くのが合理的で、テストが苦手な人やテストを書きにくい領域では後からテストを書くのが合理的なのだと思います

[trace22]

最初から自動テストが書けるのは解こうとしている問題と結論が明らかでないと極めて非効率だし、そんな簡単な仕事ばかりではない

[raimon49]

動くものを人に見せてフィードバック貰えた方が開発する側としてもモチベーションにもなるし、これは分かる。

[tk_musik]

でもテストファーストの話、あれって一度価値を出したらその後も迅速な価値を求められ続けてリファクタリングのターンが来ない、だからテストからやる、って話なんじゃないの。机上の空論度そんなかわらんとおもう。

[luege_traum]

UIとかなら同意だし、とにかく一気通貫で動かすものを作れば第三者検証も回せる。何でもテストファーストだのラストだのにすりゃ良い訳じゃなくて、時と場合に応じて柔軟にやりましょうって話に尽きるかと

[takeag]

テスト書くと遅くなるって考えの時点でちがうんだよなー。

[totoronoki]

まずは見せるところをスタートにするの良いよね。

[Cion]

自分の経験上この形式でやったプロダクトはテストとリファクタの時間取れずにおわったんだけど、皆やれてんのかな

[yosio_ism]

リリースした後にその機能のテスト書いたりリファクタをするチャンスはあんまりないよね…

[rryu]

UI関連だとテストコードを用意しなくても実行できるので優先順位が低い訳で、モジュールやAPIはそれを実行するためにテストコードを利用した方が早いというだけだと思う。

[pmint]

レビューはテストの一種。アサーションもそうなので、実際にはテストしながらの実装。「テストファーストじゃないほう」は呼び名もないほど当たり前のことで「自動テストじゃないほう」もそう。

[takc923]

僕も大体同じ順番でやってる

[nasustim]

「最悪このままでもリリースできる状態」の安心感わかるなぁ。自分は新しいモジュールを作るときには 大枠の機能を作る → 作った分のテストを書く → 細かい挙動とテストを詰めていく でやることが多い

[ducktoon]

趣味か仕事かで変わってくる。仕事だと最後になってもなるべく書かない (書いても評価されないどころか仕事が遅いと見なされる)

[twotiger]

一概にウォーターフォールよりアジャイルが優れてるとか、動的型付けより静的型付けが優れてるとは言い切れないみたいな話か

[kfujieda]

テスタブルな設計ができていて、テスト環境も整っているならいつ書いてもいいと思うけど、自分の書いたコードの動作確認を手と目でやるのはもう嫌だな。

[koyancya]

もう出来上がってるのに後からテストだけ書けるの、精神力が高い

[wkpn]

ゲーム開発では作ってたパートがまるっとなくなることもあるし、なくなるもののためにテストを書くのは馬鹿らしいので、テストラストはすごく良いと思った。

[kabakiyo]

自分もそんな感じ。APIとかはテストを先に書くけどね。inとoutが先に決まってるから。

[spam_lover]

マジでガワだけっすよ？イイっすか？イイっすか？で見せたら、プレス打とうとするのほんま草

[saikyo_tongaricorn]

雑に作る→作りこむ準備をする→新しい仕事が降ってくる

[pokepirk]

ちゃんと趣旨を理解してるブコメと、ただのテストしない言い訳の材料にしてるブコメがあるな。

[tanority]

そんなに簡単に割り切れるんだっけ？ テストする事でわかる部分と別に後回しでもいい部分ってのがあるような気がするけど。 テストしてバグなんで大きく作り直しってことにはならんのかな？

[turanukimaru]

雑に作るときは正常系実行確認程度の雑なテストを同時に作りたい。挙動確認を1クリックで済ませたいのと、雑なテストすら維持するのが難しい場合はだいたい設計とかデータの持ち方を間違えてるからだ。

[at_yasu]

CS-Fixer とかを通すとガッツリ変更量が増えるごめんなさい。

[tg30yen]

世の中の大体の開発はこうじゃない？

[ledsun]

テストコードだけをテストっていうから誤解を生むのでは？（テストコードなしの）動くソフトウェアを作って「作りたい物は何か？」をテストしてそう。そういう意味では、ユースケースシナリオが最初のテストなのかも

[nihonbuson]

テスト作成は手段なので、「どのタイミングでテストを書くか」ではなく「どんな目的でテストを書くか」をハッキリさせてくれというお気持ち。なのでテストファーストもテストラストも必要な場合があると思ってます。

[zyzy]

静的型付き言語だと、テストを先に書く動機の大半が達成できちゃうし。

[ema_hiro]

仕様が変わらないことが条件のリファクタリングのときは先にテスト書くけど、普通の機能実装してるときはあとからテスト追加することは多い、というかほぼそれ。ただまぁテストの目的に依存しそうな話ではある。

[aoken_is_god]

わ

[hatest]

イーロン曰く「雑に作って、それから作り込んで、最後にリリースしてユーザーがテストさせられる（修正はリコールで）それが『テス(ﾄ)ラ(ｽﾄ)』開発」

[auto_chan]

汎用的なちっちゃい部品は作りながらテストしちゃったほうが楽、結合した機能はどうせ仕様が変わるのでそこそこ固まってからテストだね！

[odan3240]

実装書きながらこの辺壊れやすいしテスト書いておくかという流れがいいんだなと最近思ってる

[rck10]

ビジネス都合で技術的負債を積むことはよくある話。問題は、客がその後のテスト＋リファクタコストを削減しようとすること。未来の開発者の為のコストはとかく無視されがち。

[shag]

後からテストを書ける人。つまり最低一度はテストファーストでプロダクト書き上げたことがある人向けのやり方だよね。全体の絵が見えてないと出来ないので、初心者が間に受けると痛い目に合う。

[MARKDK]

ビジネスには当然時間的な制約があるので、それとの兼ね合いで重要度が低い機能は手動テストのみでリリースはありだと思う。ただあとからテストを書く時間なんてものはそうそうやってこないと思うが

[naopr]

納得。現実的かつ合理的な開発スタイルだと思う