タグ

TDDに関するkimutanskのブックマーク (15)

  • テスト(コード)レビューの方針 書きなぐり版 - うさぎ組

    牛尾さんのブログをはてブったら、「じゃぁ、その手を見せろやゴルァ」と言われたので書きました。雑です。すみません。 元記事 「自動化対象のユニットテスト(単体テスト)の仕様書を書くことは完全なる無駄である」 Blogs - Live DevOps in Japan! - Site Home - TechNet Blogs 僕のコメント 「だいたい同じ意見だけど、これで単体テスト仕様書がいらない理由にはならないかなぁと思った。テストレビューの成長方法について書かれていないしなぁ。出来る人いない現場は諦めろってことかな?」 はてなブックマーク - kyon_mm のブックマーク - 2016年1月25日 牛尾さんのコメント「どっかに書いてありますか?もしあったら記事にはります。」 僕のコメント「書いていません!」 僕のコメント「書きました!」 僕の主張 記事は僕の実験結果(経過報告)であり、

    テスト(コード)レビューの方針 書きなぐり版 - うさぎ組
    kimutansk
    kimutansk 2016/01/25
    モックやらテストダブルを使ったテストは「~~の条件」とは書いていましたが、テスト対象外と示せば確かにより明確。なるほど。
  • 実践テスト駆動開発(GOOS)読んだ - Qiita

    実践テスト駆動開発を読んだ(和智さんいい仕事、ありがとう!)。 タイトル(GOOS = "Growing Object-Oriented Software, Guided By Tests")に、「テスト(TDD)」と「オブジェクト指向(Object-Oriented)」と「育てる(Growing)」が入っていて、ずっと読まなきゃと思っていた。出たときに角谷さんに「これは!」、と薦められたのに、機会を失っていたけど、最近、astahの開発でテストに悩みがあって読んでみた。 外から攻めるか、内からか テストを書いてプロダクトコードを育てていくという話なのだが、内側のテスト(ユニットテスト)と外側のシステムテスト(受け入れテスト、システムテスト、エンド・トゥ・エンド(E2E)テスト)をどっちを先に書くべきかいつも悩む。外側のテストを書いて、内側に進んでいくのか、内側から組み上げるか。設計の方向

    実践テスト駆動開発(GOOS)読んだ - Qiita
    kimutansk
    kimutansk 2014/08/11
    「外から攻めるか、内からか」と。内側から組む方がやりやすいですが、要求を固めたい場合は外側からやらざるを得ませんね。ただ、こういう方向を自覚しておくのは重要ですか。
  • TDDにおける品質保証の考え方

    TKG @oreshio @kz_suzuki 似たようなこと言われたことあります。自動テストの効果がわからないので、テストコードを書いたときや自動ビルドのなかで見つかったバグをチケット(もしくは後から集計できるもの)に記載してください、と・・・。もちろん断りました。 2014-06-12 00:04:00

    TDDにおける品質保証の考え方
    kimutansk
    kimutansk 2014/06/15
    TDD適用時に適用前の感覚でバグ票切ろうとすると確かにこういう対応になりますねぇ。考え方が変わったのだから対応も変えないと。
  • 【翻訳】TDD is Fun - diskogs's diary

    @solnicが、DHHの例の記事へのカウンター的な記事をポストしてまして、自分のために読んでみたらよい内容だと思ったので、翻訳してみました。翻訳ミスとかあると思いますが、、、すみませんです。。。 TDD is Fun Posted by solnic on Apr 23 2014 著 solnic 2014年4月23日 Today DHH published a blog post about TDD being dead (to him at least). It’s really not that surprising since from what I know (please correct me if I’m wrong) David’s experience is mostly based on building web apps with Rails. I get that

    【翻訳】TDD is Fun - diskogs's diary
    kimutansk
    kimutansk 2014/04/27
    「自分のシステムにおいて期待する振る舞いを記述するテストを書き、それをパスさせなさい」と。それをベースに後は考えなさいということなんでしょうねぇ
  • TDDは死んだ。テスティングよ栄えよ。 by DHH | 2014-04-24 - やっとむでぽん

    DHHの"TDD is dead. Long live testing."を、訳してみました。 翻訳 やっとむ By David Heinemeier Hansson on April 23, 2014 著 David Heinemeier Hansson 2014年4月23日 Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming. テストファースト原理主義は禁欲のみを唱えた性教育のようなものだ。つまり、自己嫌悪に陥っている人に向けた、非現実的で効果のない、道徳教育のようなものだ。 It didn't start out like that. When I first disco

    TDDは死んだ。テスティングよ栄えよ。 by DHH | 2014-04-24 - やっとむでぽん
    kimutansk
    kimutansk 2014/04/24
    何でも極端に、原理主義的に適用して思考停止するのはよろしくないよ、ということですかね。ユニットテストは便利ですが、そのためにアーキテクチャを歪めては本末転倒だと。
  • TDD is dead. Long live testing. (DHH)

    By David Heinemeier Hansson on April 23, 2014 Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming. It didn't start out like that. When I first discovered TDD, it was like a courteous invitation to a better world of writing software. A mind hack to get you going with the practice of testing where no testing had happen

    kimutansk
    kimutansk 2014/04/24
    題名が妙に過激ですが、内容的にはユニットテストだけではテストは足りないよ、という内容なので、納得ではあります。
  • テストコードを書く文化を根付かせたい─和田卓人|【Tech総研】

    におけるテスト駆動開発(TDD)のスペシャリストとして知られる和田卓人氏。講演活動やハンズオンイベントを通してテストの重要性を語り続けている。その深奥にあるプログラムの哲学とは── 父親がデータベース設計を得意にするソフトウェア・エンジニアで、受託開発の会社を経営していました。私は大学在学中からその仕事を手伝っていて、その延長で大学を出るとその会社の一員になりました。 そのころのことで一番印象に残っているのは、電子政府関連の公共システム開発に関わる大規模プロジェクトへの参加です。複数のSIerやソフトハウスが関わり、要件定義に時間をかけ、膨大な設計文書をつくっては、何千人というエンジニアを投入する、典型的な大規模システム開発です。私はそこにSEの一員として参加することになりました。 ただ、私は初日から生意気にも「Excel設計書を書き続けるために来たのではありません」と嘆願して、基盤

    kimutansk
    kimutansk 2014/03/31
    実際に手を動かしてみる/他社のエンジニアと交流する/自分のスキルの多様性を保ち、複数の分野を学び続ける・・・と。仰る通りですね。プログラマはそうでないと
  • 自動テストの誤解とアンチパターン in 楽天 Tech Talk

    2014/02/12の楽天Tech Talkに登壇させてもらったときの発表スライドです。 2013年に発表したいくつかの内容をまとめました。 基的に、ソフトウェアテストの絶望を聞きたい人向けです。Read less

    自動テストの誤解とアンチパターン in 楽天 Tech Talk
    kimutansk
    kimutansk 2014/02/12
    「プロダクトコードをレビュー出来るレベルでなければROIの高い統合テストは書けない」「TDDの効果は属人性排除と意味不明なドキュメントの防止」と。
  • テスト駆動開発へようこそ

    和田 卓人 タワーズ・クエスト株式会社 取締役社長 「百聞は一見に如かず」といいます。テスト駆動開発 (TDD) を理解するには、実際に行っているところを見るのが一番です。このセッションでは、ライブ コーディングによるデモを通じて TDD の実際の姿をご覧頂きます。 受講対象: DevOps 導入前に、テスト駆動開発 (TDD) を実現できていない方、TDD のやり方をご存知ない方はぜひご参加ください。 製品/テクノロジ: DevOps/開発言語/OSS

    テスト駆動開発へようこそ
    kimutansk
    kimutansk 2014/02/01
    具体的にどうやるか、がまとまっているのでわかりやすいですねぇ
  • これであなたもテスト駆動開発マスター!?和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します~現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd|CodeIQ MAGAZINE

    和田卓人さんによるテスト駆動開発問題解説の寄稿です! バグのないよいコードを書くには、よいテスト設計が重要です。今回は現在時刻に関する問題と、その問題で提出された実際の解答コードを紹介しながら、どのようにテスト設計し開発していくのかを解説していきます。 ゲスト解答による解答コードも公開中! by CodeIQ運営事務局 はじめに こんにちは、和田(@t_wada)です。今日は先日出題させていただいたTDDに関する問題の総評を行いつつ、テスト容易性設計について考えてみたいと思います。 問題文 私が出した問題は、以下のようなものでした。 問1. 下記の仕様をテスティングフレームワークを使ってテストコードを書きながら実装してください。 【仕様1】 「現在時刻」に応じて、挨拶の内容を下記のようにそれぞれ返す機能を作成したい。 (タイムゾーンはAsia/Tokyoとする) 朝(05:00:00以上

    これであなたもテスト駆動開発マスター!?和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します~現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd|CodeIQ MAGAZINE
    kimutansk
    kimutansk 2013/11/27
    「外部環境との界面にインターフェイスを作成し、テストダブルで置き換える」はやり過ぎを招きやすい・・は確かに。非常によく使う手法ではあるんですが。にしてもいいまとめです
  • TDDの効果の研究をまとめた研究 - やっとむでぽん

    TDDに関連する論文をいろいろ探し回っていたのですが、今年(2013年)に書かれた、既存のTDD研究をまとめて全体像を描こうとしている研究を見つけ、しかも無料で公開されているので、紹介したいと思います。 以下のように書いてあるので、学会(?)発表用のものであって、雑誌に載ったわけではないのかな(アカデミックな話はよくわからない。査読があるかどうかが重要なんだっけ)。 This is the author's version of the work. The definite version was published in Proceedings of the 6th International Conference Software Quality Days (SWQD 2014), Vienna, Austria, January 14-16, 2014 "Effects of Tes

    TDDの効果の研究をまとめた研究 - やっとむでぽん
    kimutansk
    kimutansk 2013/11/10
    統計を取ったとしても「欠陥は減る、工数は増える、あとは微妙という話しかできない」と。1回の開発だとそうなりますか・・・
  • 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
    kimutansk
    kimutansk 2013/10/21
    「障害の数を管理するのではなく、障害を早い段階に少ないコストでつぶすことができるように、アーキテクチャーをコントロールすること、プロジェクトをマネジメントすることが、品質管理の主眼となる」
  • 私にとってのテスト

    DevLOVE X Day1 C-5のセッションです。 ITの活用範囲の広がりとともに、費用・品質よりもデリバリを優先するプロジェクトも増えてきました。しかし「しっかり考えるよりも、作ってリリースしちゃおうぜ、正解なんて誰にも分からないんだから」というマントラを唱えながら、返済見込みの立たない大量の技術的負債を抱える。それが最善の選択なのか、もう少しだけ立ち止まって考えてみませんか? YAGNIという言葉を便利に使いすぎてはいませんか? コードを書きなぐるのと、ちょっと考えて設計して作るのとで、そんなに開発スピードに違いがありますか? 考えてみたいと思います。

    私にとってのテスト
    kimutansk
    kimutansk 2013/07/26
    自動テストがあるからこそ悪いところはギリギリまで何とかするべく対応できるのはわかります。あきらめなくてもよくなる。
  • 愛せないコードを書くには人生はあまりにも短い

    愛せないコードを書くには人生はあまりにも短い Dec 16, 2012 @ DevLOVE 2012 Read less

    愛せないコードを書くには人生はあまりにも短い
    kimutansk
    kimutansk 2012/12/18
    なんとなくもやもやしているものを見えるようにするには役に立つ・・? 表現的には微妙かもしれませんが
  • 書籍:実践テスト駆動開発 - haru01のめも

    実践テスト駆動開発 (Object Oriented SELECTION) 作者: Steve Freeman,Nat Pryce,和智右桂,高木正弘出版社/メーカー: 翔泳社発売日: 2012/09/14メディア: 大型購入: 4人 クリック: 262回この商品を含むブログ (31件) を見る 実は、ちょっと不満がある。だた、この不満は、オブジェクト指向設計/テスティング活動ついての、きわめて個人的な信条/大切に考える価値判断に由来している。個人的な不満。 このは、オブジェクト指向設計、テスティングが主題なのだが、どうしてドメインエキスパートとの対話をあまり描かず、OOやテスティングを説明したのだろうかと(対象を明瞭に記述しようとするこだわり/気配りを凄く感じるのに)。DDDが、がんばって対話について説明しようとしたように、もう少し触れてほしかった。 Fitががんばって説明したように

    書籍:実践テスト駆動開発 - haru01のめも
    kimutansk
    kimutansk 2012/10/16
    テストコードを書くときにひたすらモックとリフレクション乱発になった事があるので。。。読んでみますか。
  • 1