気に入った記事をブックマーク
- 気に入った記事を保存できます
保存した記事の一覧は、はてなブックマークで確認・編集ができます
- 記事を読んだ感想やメモを書き残せます
- 非公開でブックマークすることもできます
エントリーの編集
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
記事へのコメント106件
- 注目コメント
- 新着コメント
t-wada
仕様が固まることはないので、テストが得意な人やテストを書きやすい領域では粗く雑なテストを同時に書くのが合理的で、テストが苦手な人やテストを書きにくい領域では後からテストを書くのが合理的なのだと思います
tk_musik
でもテストファーストの話、あれって一度価値を出したらその後も迅速な価値を求められ続けてリファクタリングのターンが来ない、だからテストからやる、って話なんじゃないの。机上の空論度そんなかわらんとおもう。
luege_traum
UIとかなら同意だし、とにかく一気通貫で動かすものを作れば第三者検証も回せる。何でもテストファーストだのラストだのにすりゃ良い訳じゃなくて、時と場合に応じて柔軟にやりましょうって話に尽きるかと
xlc
仕様が決まったらテストを書く、という話かと思う。請負なら仕様は最初から決まっているが、挑戦的なプロダクトなら最初は実現可能かすら分からないことだってある。そのためのプロトタイプにテストは要らんだろ。
nasustim
「最悪このままでもリリースできる状態」の安心感わかるなぁ。自分は新しいモジュールを作るときには 大枠の機能を作る → 作った分のテストを書く → 細かい挙動とテストを詰めていく でやることが多い
turanukimaru
雑に作るときは正常系実行確認程度の雑なテストを同時に作りたい。挙動確認を1クリックで済ませたいのと、雑なテストすら維持するのが難しい場合はだいたい設計とかデータの持ち方を間違えてるからだ。
ledsun
テストコードだけをテストっていうから誤解を生むのでは？（テストコードなしの）動くソフトウェアを作って「作りたい物は何か？」をテストしてそう。そういう意味では、ユースケースシナリオが最初のテストなのかも
nihonbuson
テスト作成は手段なので、「どのタイミングでテストを書くか」ではなく「どんな目的でテストを書くか」をハッキリさせてくれというお気持ち。なのでテストファーストもテストラストも必要な場合があると思ってます。
ema_hiro
仕様が変わらないことが条件のリファクタリングのときは先にテスト書くけど、普通の機能実装してるときはあとからテスト追加することは多い、というかほぼそれ。ただまぁテストの目的に依存しそうな話ではある。
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
いまの話題をアプリでチェック！
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
雑に作って、それから作り込んで、最後にテストを書く「テストラスト」開発 - give IT a try
（この話は最初Twitterに書こうと思ったけど、長くなるのでブログに書くことにしました） 僕はRSpecやMi... （この話は最初Twitterに書こうと思ったけど、長くなるのでブログに書くことにしました） 僕はRSpecやMinitestでテストを書くのは得意ですが、常にテストファースト（TDD）で開発するとは限りません。 今業務でやってるタスクはこんなふうに進めてます。 雑に動くものを作る ↓ 見た目をきれいにする＆機能を作り込む ↓ テストを書く ↓ リファクタリングする この順番で開発する理由を以下に述べます。 雑に動くものを最初に作る理由 最初は見た目とか、異常系とか、細かい仕様とかを無視して、正常系が一通り動くものを作ります。 これはこれから作ろうとしているものの認識が合っているかどうかをPO（プロダクトオーナー）に確認するためです。 実際に動く画面を見せると「こんな感じでOK」とか「ここはこういうふうにしたい」というフィードバックをもらうことができます。 また、開発者としてもコードを書きな
ブックマークしたユーザー
すべてのユーザーの
詳細を表示します
詳細を表示します
2023/02/16 リンク