タグ

tddに関するkamatama_41のブックマーク (45)

  • アジャイル開発とTDDを半年間実践してみた顛末と、これから

    PHP Conrefence Japan 2011 Sep 10thでの発表資料 http://phpcon.php.gr.jp/2011/Read less

    アジャイル開発とTDDを半年間実践してみた顛末と、これから
    kamatama_41
    kamatama_41 2011/09/13
    会社じゃ見れないので、後で読む
  • [動画で解説]和田卓人の“テスト駆動開発”講座 記事一覧 | gihyo.jp

    第16回プログラミング言語とTDDは、どちらを先にマスターすべきか? 和田卓人 2007-12-21

    [動画で解説]和田卓人の“テスト駆動開発”講座 記事一覧 | gihyo.jp
  • RspecとCucumberでTDD/BDDを極める (The Rspec Bookの紹介) - Masatomo Nakano Blog

    の紹介第2弾。少し前、Twitter上でTDD/BDDについて盛り上がっていたので、このを紹介してみたくなった。 「The Rspec Book: Behaviour Driven Development With Rspec, Cucumber, and Friends」という。 このは、RspecとCucumberを使い、どう考え、どうシステムを作っていくか、というをチュートリアルを交えながら紹介する構成になっている。 ただUnit Testを紹介するだけではなく、Unit TestツールであるRspecに、BDDツールであるCucumberを組み合わせて使うことで、Unit Testでカバーできない部分をCucumberで補い開発をする、というところがこのの肝になっている。 このを読み、実践することで、Unit Test*だけ*を書いてシステムを作っているときのモヤモヤ感

  • TDDBCでの教えを胸に、巨大なC#レガシーコードと戦ってみた - hachiNote

    目的 業務で現在、とても厄介なC#コードと戦っています。途方に暮れかけていましたが、TDDBC札幌で教えていただいたことから突破口が見えてきました。感謝の気持ちを表しつつ、ちょっとした現状メモです(それにしてはすごく長くてすみません)。 正確には「戦ってみた」じゃなくて、「戦い始めた」ですね。 敵のデータ どんなアプリケーションか C#で書かれた(一部C++もあるが)Windowsフォームアプリケーション。ドライバ的なところからビューアまで、かなり巨大。 とりあえず今自分が見ているところはビューアの改造とかのわりと表層的な部分。C#のみ Visual Studio 2008 Professional Edtionで開発 コードの状態 コードの質が悪すぎる。今までみたコードの中で最もひどい コピペコード多すぎ。とにかくところかまわずがんがんコピペ状態。 メソッド長過ぎ。クラスがでかすぎ。Cじ

    TDDBCでの教えを胸に、巨大なC#レガシーコードと戦ってみた - hachiNote
    kamatama_41
    kamatama_41 2011/08/18
    とにかくテストを書く!
  • xUnitに関するパターン・Fixture(フィクスチャ) - Strategic Choice

    Q:複数のテストで必要とされる共通のオブジェクトをどのように作成するのか。A:テスト内のローカル変数をインスタンス変数に変換する。セットアップ用メソッド(=@Beforeアノテーションを付加したメソッド)を作成し、そのインスタンス変数を初期化する。どうして?テストコードにおいて、ある状態にオブジェクトを設定するためのコードを、テストの「フィクスチャ(土台)」と呼びます。オブジェクトを操作し結果をチェックするコードよりも、このフィクスチャが大きくなる場合が「しばしば」あります。しかもフィクスチャは複数のテストで同じである場合が多いです。この重複には不都合があります。コピーアンドペーストしても、作成に時間を要します。テスト作成は迅速に行いたいところです。オブジェクトを変更する必要がある場合、複数のテストに変更を行わなければいけません。まさに重複の弊害です。モデルコードから重複を取り除く必要があ

  • TDDと単体テストって別物だよね - @ikikko のはてなブログ

    仕事で単体テスト仕様書を作っていたのですが、しっかりダメ出しされました…orz 今まで、単体テストなんてxUnitを使ってTDDとか言ってればそれなりのものはできるでしょ♪ぐらいで、真剣に考えたことはありませんでした。けど、今回ダメ出しをされたことをきっかけに、どのようなテストの設計・手法だとプログラムの品質が確保されるかを考えてみることに。 ちなみに、現在はABAP関連の仕事をしているので、xUnitはABAPUnit。残念ながら、ぐぐっても、日語の関連文献は見つかりませんでした。暇を見つけて、このシリーズの和訳でもしてみようかな… 閑話休題。 巷でよく話題になるTDDは、使い方も含めてそれなりに知識としては頭に入っています。けれど、それをうまく単体テストとして、仕様書に落とし込めないなぁと悶々としていました。 どうゆうことだろう?と調べてみると、以下の記事を見つけました。ちょっと古い

    TDDと単体テストって別物だよね - @ikikko のはてなブログ
  • Shibu's Diary: 「TDD/BDDは不完全な単体テストを誘導する?」

    渋日記@shibu.jp 渋川よしきの日記です。ソフトウェア開発とか、ライフハックを中心に記事を書いていきます。 TDD/BDDは不完全な単体テストを誘導するという記事が出ています。要点としては、TDD/BDDは、特定のケースの検証をしているにすぎず、アプリケーション内部で発生しうる、すべてのケースの検証をしているわけじゃない、ということです。まぁ、考えてみれば当たり前なんですけどね。 カバレッジだけを考えても、C0(命令網羅)、C1(分岐網羅)、C2(条件網羅)と3段階あります。現実的に考えて、アプリケーション全体の条件網羅を行うのは不可能です。if文が32個あれば、2の32乗です。42億通りです。実際は、ネストしたりいろいろあって、完全にすべてのif文が独立、ということはないので、これよりも遙かに少なくなりますけどね。完璧なテストはムリですよね。 実際はなるべく少ない手数で効率よくテス

  • TDDはテスト手法か否か

    なんもわからん @babie TDDは論理実証主義的な面が強調されすぎたために、BDDなどという言い換えが行われた。反証主義的に、エラーを積極的に起こそうとするテストを書くべき。 2010-02-21 13:45:09

    TDDはテスト手法か否か
    kamatama_41
    kamatama_41 2011/08/08
    内容が難しいけど読もう。
  • なぜ、個人のサービスなのにテストを書くのか。 « blog.udzura.jp

    以下のエントリは、自分内ブレインストーミングの結果を書き起こしただけのモノなので、数年後どころか数ヶ月後でも意見が変わっているかもしれない。と言う前提で。 三つ、考えられる。 「未来の自分」が楽になる 自動テストコードは、その状態でのそのソフトウェアの挙動、仕様のスナップショットを撮る、と言う側面があり、それはドキュメントを各行為にも通じるが、「今書いている」自分以外の誰かがそのソフトウェアを変更したり、メンテナンスしたり、理解する際に役に立つ。人間はモノを忘れていく以上、「今書いている」自分以外、とは、当然未来の自分も含まれる。 実際、経験的にも、変更したらまずは rake spec を走らせて、エンバグしていないことを確認できるのは気持ちがすごく楽……。そのサービスを変えつづけていくつもりなら、是非テストを書こう。必ずいいことがある。 で、以下二つは、コードをgithubなどのソーシャ

  • 社内向けにTDDの講習会を行いました - anfangsのログ

    勤め先でTDDの講習会を行ったので、その内容について書きます。 この記事がTDD導入を検討している方の力になれば幸いです。 経緯 私はとあるSIerに務めており、部内ではテストの工数を削減することが課題となっています。 以前からTDDを同僚や先輩に宣伝していたこと、また、理解ある上司に恵まれたこともあって、 テストコードの書き方を講習する時間をもらえました。 そこで、TDDBCの要領で楽しみながらTDDを学んでもらうことにしました。 一人ではつらいので、TDDBCの参加経験がある先輩と二人で講習を行いました。 参加者について 若手開発者 3名 中堅開発者 2名 業務にオブジェクト指向の考え方を取り入れたのは2,3年ほど前?らしい。(要出典) 普段はC#、VisualStudio、VSSを使っている。 講習の目的 二人で話しあい、講習の目的を以下のように決めました。 テストコードの書きかたを

    社内向けにTDDの講習会を行いました - anfangsのログ
    kamatama_41
    kamatama_41 2011/07/23
    弊社でもやりたい
  • 札幌 Java カンファレンス 2011開催しました - やさしいデスマーチ

    札幌 Java カンファレンス 2011 with TDD BootCamp 札幌サテライトを開催しました。最終的には、来場者数55名、事前キャンセル6名、ドタキャン1名となりました。スタッフや講師を除外しても50名以上が参加され、当にありがとうございます。当日にはポストできませんでしたが、簡単にレポートをまとめておきます。 今回のイベントは、Java7のLaunchイベントの一環として札幌で何かできないか?という相談を寺田さん(@yosioterada)から頂いた事がキッカケです。そこで開催しなかったら、札幌Javaコミュニティを立ち上げた意味がありません。快諾し、日程を調整した結果、7月9日開催となりました。 ところが、TDD BootCamp東京も運悪くバッティング。実は参加を企んでいたのですが、未遂に終わります。しかし、各地でサテライト開催の企画があがっていたため、札幌も便乗する

    札幌 Java カンファレンス 2011開催しました - やさしいデスマーチ
    kamatama_41
    kamatama_41 2011/07/11
    あとで読む
  • TDD BOOT CAMP in TOKYOに行ってきました! - ShiroKappa Blog

    2011/07/09に開催された「TDD BOOT CAMP in TOKYO」に行ってきました。 まずは、Symfonyしゃべりばでのひょんなきっかけから、この素晴らしいイベントの主催をされた[twitter:@HIROCAST]さん、会社でもお世話になっておりますが、開催協力と講演をしてくださった[twitter:@t_wada]さん、各言語をサポートいただいた[twitter:@shishi4tw]さん、[twitter:@setoazusa]さん、[twitter:@kyon_mm]さん、[twitter:@sue445]さん、設営から運営をサポートしてくださった方々、LTをしてくださった[twitter:@remore]さん、[twitter:@tomy_kaira]さん、Ustの配信にご尽力いただいた[twitter:@brtriver]さん、[twitter:@gilbite

    TDD BOOT CAMP in TOKYOに行ってきました! - ShiroKappa Blog
    kamatama_41
    kamatama_41 2011/07/11
    TDDは組織的に運営しようというお話。
  • TDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめ

    8. ____ /⌒ ⌒\ /( ●) (●)\ /::::::⌒(__人__)⌒::::: \ 簡単だお! | |r┬-| | \ `ー'´ / 3か月前の@remore 9. ____ /⌒ ⌒\ /( ●) (●)\ /::::::⌒(__人__)⌒::::: \ 簡単だお! | |r┬-| | \ `ー'´ / 後に現実を知ることになります

    TDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめ
    kamatama_41
    kamatama_41 2011/07/10
    TDDは1日にしてならず、ということですね。
  • https://objectclub.jp/technicaldoc/testing/stack_tdd.pdf

  • Halobet 🎀 Situs Slot Online Terpercaya Gacor 2024

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

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

    「テストをすべきなのは知っているが,現実にはできない」という現場の状況をいかに打破するか,気鋭のソフト開発者とテスト技術者がパネル討論
  • TDDBC Fukuoka Day1

    TDD Boot Camp Fukuoka Day1 - Mar 19, 2011 at FukuokaRead less

    TDDBC Fukuoka Day1
  • はたして、TDDを前提として障害収束曲線が描けるのか?

    前のアーティクルで自分で言及してなんだけど、ものすごーく気になったので、思考実験。 規模は数人3ヶ月を想定してみた。 従来の障害収束曲線 障害収束曲線は色々呼び方があって、最も短い呼び方ではバグ曲線とか呼んだり、Wikipediaでは信頼度成長曲線という名前で出ていたりする。 基は「テストを重ねていけば、自然と障害検出数が低くなっていくよね。」という「現象」を取り扱ったもの。 図としてはこんな感じかな。 図は、製造フェーズ後にテストフェーズが「単体テスト」・「結合テスト」・「受入テスト」と分かれている事を想定している。 (テストフェーズも、現場や企業の慣習によって大きく扱いが違うので、この程度にした) 「恣意的だ」とツッコミが入るだろう部分を先に解説。 件数多くね? … 過去3ヶ月もテストフェーズがある場合、これぐらいじゃなかったかな?という経験則。(件数に厳密な意味などない) ブレがな

    はたして、TDDを前提として障害収束曲線が描けるのか?
  • なぜUnitTestは理解されない?

    TwitterでこんなTweetが流れた… エビデンスとしてNUnitGUIのスクリーンショットと、対応するテストコードが含まれている部分のVSのスクリーンショットを取る作業が終りません・・・ UnitTestのエビデンスって…なに? 一般的にテストのエビデンスというと、次の2点を指す。 テスト手順を明らかにするもの(ex. テスト設計書、テスト仕様書、...) テスト結果の証拠(ex. 画面ハードコピー、DBスナップショット、...) UnitTestでは、これはこのように解釈できる。 テスト手順を明らかにするもの = テストコード テスト結果の証拠 = 今実行すればテストが全てグリーンになること これがなぜか理解されず、軋轢とストレスと大きな工数追加になっている現場がずいぶんある。 なぜUnitTestはいつまでも理解されないのだろう。 余談。これらのことは、Seleniumなどを使

    なぜUnitTestは理解されない?
  • Login | Microsoft 365