タグ

TDDに関するmohrisのブックマーク (12)

  • 【実践的ユニットテスト入門】自動テストの応用的な使い方は? リファクタリングとTDDを紹介

    はじめに BASE株式会社でシニアエンジニアを務めているプログラミングをするパンダ(@Panda_Program)と申します。連載はPHPカンファレンス2022での発表「実践!ユニットテスト入門」を再構成して記事としたものです。 対象読者 連載の対象読者は、自動テストの必要性をわかっているもののまだテストコードを書いたことがない開発者の方です。さらに記事では、テストコードを書く習慣が身についている中級者の方にとっても自動テストに対する理解を深める助けになるでしょう。 テストを上手に活用してソフトウェア開発を加速させる 前回は、Dev(開発)のみならずOps(運用)にまで視点を広げることにより、ソフトウェア開発の全体像におけるテストの位置付けを説明しました。ここからは視点をDev(開発)の自動テストに戻しましょう。 連載を通して、自動テストの意義は開発者がリリース前にバグを見つけるこ

    【実践的ユニットテスト入門】自動テストの応用的な使い方は? リファクタリングとTDDを紹介
  • 【翻訳】テスト駆動開発の定義 - t-wadaのブログ

    このブログエントリでは、テスト駆動開発(TDD: Test-Driven Development)の考案者Kent BeckがTDDの定義を改めて明確化した文章を、許可を得たうえで翻訳し、訳者の考察を沿えています。 きっかけ 2023年の年末、テスト駆動開発(TDD: Test-Driven Development)の考案者Kent Beckは、substackにTDDに関するポストを連投して論戦を繰り広げていました。TDDはその誕生から20年以上が経ち、その間に「意味の希薄化」が発生して議論が噛み合わなくなっていました。意味の希薄化(Semantic Diffusion)とは、新しく作り出された用語が広まる際に来の意味や定義が弱まって伝わる現象です。 私(和田)はTDDと関わりの深いキャリアを歩んできました。Kent Beckの著書『テスト駆動開発』の翻訳者であることもあり、TDDの正

    【翻訳】テスト駆動開発の定義 - t-wadaのブログ
  • 実録レガシーコード改善 / Working with Legacy Code: the True Record

    2024/01/15(月) 12:00 〜 13:00 t-wadaさんが後世に残したい、実録レガシーコード改善 https://findy.connpass.com/event/304101/ テストコードが無いコードを引き継いだところからはじまる、実際に2018年に行った受託開発案件のエ…

    実録レガシーコード改善 / Working with Legacy Code: the True Record
  • TDDでデータベースと付き合う方法

    はじめに データベースを読み書きする部分のユニットテストがやりにくいのには、いくつか理由があります。 複数人でテストを同時に実行すると、競合する データベースを使ったテストは、時間が掛かる データベース内のデータが変わると、テストが失敗する 1番目は、各自の開発環境にテスト用のデータベースを用意することで、解決できます。2番目の問題は、データベースにアクセスするコードをロジックから分離して、データベースに実際にアクセスするテストケースを減らすことで、改善できます(ロジックのテストにはモックやダミーを使います)。3番目は、テストのたびにデータベースの内容を初期化することが基になりますが、そうするとテストに長い時間が掛かるようになってしまいます。 今回は、ビジネスロジックの開発時にモックやダミーを使いやすくするにはどうするか、また、テスト時にデータベースの内容を安定させるにはどうしたらよいか

    TDDでデータベースと付き合う方法
  • Rails で、Controller に定義されている action を一度に取得する方法はありますか? - QA@IT

    平素よりQA@ITをご利用いただき、誠にありがとうございます。 QA@ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA@ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、@ITの今後のメディア運営方針などを検討した結果、2020年2月28日(金)15:00をもちましてQA@ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA@ITの7年間で皆さまの知識

    Rails で、Controller に定義されている action を一度に取得する方法はありますか? - QA@IT
  • 技術/TDD/JavaでUnitTestでprivateメンバにアクセスしたい場合 - Glamenv-Septzen.net

    id: 449 所有者: msakamoto-sf 作成日: 2009-10-03 15:44:05 カテゴリ: Java TDD プログラミング テストコードを書く時に困るのが、privateなメンバをテストしたい場面である。 そもそもprivateなメンバをテストコードでテストする必要があるのか、テストしたいのならprivateではなく別のクラスに移すべきではないのか、という意見はひとまずおいておく。 ここでは、下記記事で紹介されている、Javaでprivateなメンバを外部からreflectionを使ってアクセスする手法を例によって抜き書きしてまとめておく。 "Subverting Java Access Protection for Unit Testing - O'Reilly Media" http://onjava.com/pub/a/onjava/2003/11/12/re

  • テストファーストの弊害

    テストファーストは、XP(エクストリームプログラミング)の中でも特に広く浸透したプラクティスの1つである。 テストファーストは、モノを作るよりも前に、まずテストから着手する、という手法だ。モノが無ければテストできないという常識を、根からひっくり返す斬新なアイディアは、多くのソフトウェア開発者に衝撃を与えた。 テストファーストは、短期開発におけるXPの有効性が認められ、JUnitなどのテストツールが普及した今では、広く受け入れられるようになった。 だが、このようなまったく新しい手法は、初めはなかなか受け入れられ難いが、いったん受け入れられると、今度は逆に、魔法の技術であるかのように盲信されやすい。テストファーストについても、最近では「JUnitでテストコードを書いていれば、ソフトウェアの品質は問題ない」という風潮が広まりつつあるような危惧も感じる。 テストファーストの効果は、多くの人が認め

  • Seasar Conference 2009 White にて 「テスト駆動開発のこころ」というタイトルで登壇させていただきました - t-wada の日記(旧)

    日は、SeasarCon 2009 White にて「テスト駆動開発のこころ (TDD はじめの一歩)」というタイトルで講演させていただきました。お聞きくださった皆様、ありがとうございました。 当日の資料を slideshare にアップロードしたので貼り付けておきます。 SeasarCon 2009 White TDDView more presentations from t_wada. 久しぶりの Seasar イベント登壇、楽しかったです!

    Seasar Conference 2009 White にて 「テスト駆動開発のこころ」というタイトルで登壇させていただきました - t-wada の日記(旧)
  • 僕がTDDをやめた理由 - カタチづくり

    タイトルは、まあ、半分釣り。TDDな人もそうでない人も、肩の力を抜いてお気楽にどうぞ。 題に入る前に まずお礼 ここで書くことは、前の記事 TDDはYAGNIに矛盾する? - カタチづくり から派生して色んな方と意見を交わした経験が元になっています。この場を借りて、色々とアドバイスを頂いた方に心から感謝の意を表します。 特にコメント欄にお寄せいただいた きしだ さんのコメントは、コメントと言うよりももはや一つの素晴らしい記事となっていて、もう必読といってもいいレベルじゃないでしょうか。当にありがとうございます。特にBDDについて大きなヒントを頂きました。 押し付けではなく、交換 タイトルから想像がつくとおり、ここにはどうしてもTDDに対して否定的な意見ばかりが並んでしまう。でも、だからといって僕がTDDを完全に否定しているとは思わないで欲しい。 僕が今一番恐れていることは、TDDに対し

    僕がTDDをやめた理由 - カタチづくり
  • なぜ人はテストを書かないのか? - kなんとかの日記

    「スーパープログラマー」という単語に過敏に反応する人がいたのをきっかけに、プログラマーとして一流であるための条件というのを考えてみたんだけど、難しくてわからんかった。しかし一流じゃない条件ならいろいろ思いつく。 たとえば、今なら「テストを書かないプログラマーは一流でない」ということは言えるだろう。これはどんな凄腕プログラマーだとしても当てはまる条件だ。 そして、これだけテストの重要性が叫ばれている中でもやっぱりテストを書かないプログラマーというのは存在する。これは初心者だろうが上級者だろうが関係なく一定数存在する*1。 で、なぜテストを書かないかということだが、いちばんの大きな理由は、テストを書かないのではなくて、テストが書けないだけなんじゃないかと思ってる。 テストを書いた方がいいなんてのは、誰だって分かっている。でも実際には書かない人が結構な数いて、その人たちは「ロジックは書けるけどテ

    なぜ人はテストを書かないのか? - kなんとかの日記
  • 「テストをすべきなのは知っているが,現実にはできない」という現場の状況をいかに打破するか,気鋭のソフト開発者とテスト技術者がパネル討論

    「テストをすべきなのは知っているが,現実にはできない」という現場の状況をいかに打破するか,気鋭のソフト開発者とテスト技術者がパネル討論 Developers [Test] Summit 2008(デブサミTest) 「建前ではなく実際にテストを普及させるにはどうすればいいのか」。2008年4月23日,東京・九段で開催されたテストに特化したソフトウエア開発者向けカンファレンス「Developers [Test] Summit 2008(デブサミTest)」で「【徹底討論】テストなんていらない?!-テストを,どこまでやるべきか?」というパネル・ディスカッションが開催された。 司会を務めたのはタワーズ・クエスト プログラマ兼取締役社長であり,テスト駆動開発(TDD)の日での第一人者である和田卓人氏。同氏に,オープンソース・プロジェクト「Seasar」のチーフコミッタであるひがやすを氏,テストの

    「テストをすべきなのは知っているが,現実にはできない」という現場の状況をいかに打破するか,気鋭のソフト開発者とテスト技術者がパネル討論
  • gihyo.jpにて連載させていただいたテスト駆動開発のWeb連載もとうとう最終回を迎えました - t-wadaの日記

    http://gihyo.jp/dev/serial/01/tdd/ 技術評論社様の情報サイト「gihyo.jp」にて、動画と連動した連載のかたちとして書かせていただいた今回のWeb連載も、ついに連載終了の日を迎えました。一応公約通り年内で連載終了まで来ましたね。お読みくださった方々には当に感謝いたします。ありがとうございました。 ここで連載の全記事に、リンクを張っておきます 第1回 連載を始めるにあたって 2007年10月26日 第2回 「テスト駆動開発」とは何か? 2007年10月30日 第3回 「テスト」という言葉について ── Developer Testing,Customer Testing,QA Testing 2007年11月2日 第4回 ナントカテスト ―― ユニットテスト,単体テスト,機能テスト,結合テスト,受け入れテスト 2007年11月6日 第5回 進捗管理として

    gihyo.jpにて連載させていただいたテスト駆動開発のWeb連載もとうとう最終回を迎えました - t-wadaの日記
  • 1