時間がないからこそ、テストを書く

こんにちは。 株式会社ココナラ在籍のKです。 「時間がないからテストは後で書く」 そのような言葉を聞くたび、「テストを一緒に書くことでむしろ時間を節約できるのに、もったいない」と感じます。 本記事では、その理由を明確にした上で、私がよくやっているTDDをゆるく取り入れたテストの進め方をご紹介します。 対象読者 本記事は、以下のような悩みをお持ちの方に向けた記事です。 テストの重要性は理解しているものの、時間的な制約からテストを後回しにしてしまいがち TDDに興味はあるものの、難しそうでなかなか実践できない TDDのテストファーストという手法に馴染めない チーム内にテストの文化を広めたい 本記事の構成 大きく以下の2つの構成になっています。 テストを後で書くという考え方への考察 TDDをゆるく取り入れた実践手法 本記事におけるテストの定義 本記事で扱うテストは、主としてロジックのユニットテス

[dorapon2000]

“実装前にコメントで処理内容や分岐を記述することで、テストケースを網羅的に検討するきっかけになります。”

[yohskeey]

テストの話になるといつも思うんだけどみんなユニットテストって何で知ったんだ？入門書とかだとテストについては書いてないか付録レベルで、弊社にも「ユニットテスト」というものを知らずにエンジニアしてる人多い

[t-wada]

"「テストを一緒に書くことでむしろ時間を節約できるのに、もったいない」「時間がないからテストを後で書く」のではなく、「時間がないからこそ、テストを並行して書く」" そのとおりですね

[shingo-sasaki-0529]

「TDD」はもちろん、「テストファースト」さえ最近は定義に厳しくなってきてる気がするので、「同じPRで実装とテストコードを一緒に出そう」ぐらいの緩さで運用していきたいお気持ち。

[repon]

TDDは、簡素なテストを書こうとすると自然にコンポーネントが疎結合になっていくので良いのだが、twadaさんもチームより個人で始めるのが良いとQiitaのpodcastで言ってた。自分はTDDと単体・結合テストの区切りがわからない

[fivestech]

その前にテストケースがわからないのよ、テスト分析のタイミングとやり方を教えてくれ

[kakuzator]

テストテスト言ってる奴って基本的に自社開発勤めのお貴族様だよな。受託・SESで関わるプロジェクトの9割は納品最優先で時間がないからテスト書かねーよ。

[aike]

テストのコスパは対象による感じ。機能を追加すると既存機能に影響がでがちな複雑なシステムはテスト書くと進めやすい。逆に全く独立した機能が多数ある場合もテスト書けばその機能について完全に忘れていいので楽。

[maecchi]

“「時間がないからテストを後で書く」のではなく、「時間がないからこそ、テストを並行して書く」”

[shikiarai]

内製力がないから外注するとテストコードが存在しなくて終わるのを繰り返してる

[suikyojin]

テスト駆動開発は、ずっと後から出てきた言葉だが、UTとかユニットテストという言葉は、1980年代頃にはそれなりに使われていたと記憶している。性能が低いからこそ、小規模なテストでバグを検出する必要があった。

[high-low-02-03]

ゆるくTDD、めっちゃわかる。今後は生成AIも絡んでくるので、コメントが大事になりそう。

[kmaebashi]

メソッドごとに単体テストをきっちり書いて、完璧! と思って画面とくっつけると設計上のポカが見つかって、「最初に画面から呼んでおけばもっと早く気付けたのに!」となることもあったりする。

[kubecorn]

運用フェーズに与えるダメージが大きいからねえ。カバレッジ低くても最低限書くだけでも全然違う。

[masa8aurum]

“実際、「時間がない」と言いながら画面操作に時間を費やしている人を何度も見てきました”

[Phenomenon]

ある程度実装が進んでから…ってよくわかるんだけど「ある程度」に結構違いがあって自分的にはIFが決まったらもうテスト書いちゃう。そのほうが楽ちん

[tmatsuu]

うっ、せやな