[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

タグ

programmingとTDDに関するyuki_2021のブックマーク (15)

  • 【翻訳】テスト駆動開発の定義 - 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のブログ
  • テスト駆動開発(TDD)ハンズオンのすすめ - RAKUS Developers Blog | ラクス エンジニアブログ

    こんにちは、あるいはこんばんは。すぱ..すぱらしいサーバサイドのエンジニアの(@taclose)です☆ 弊社では先日テスト駆動開発(以降、TDDと呼ぶ)ハンズオン勉強会を開催しました! 今回の記事の内容はズバリ2つ 誤解してる!?テスト駆動開発の良さ!学ぶ事の意味! TDDハンズオン勉強会を開催する意図や実施内容、感想! 読者のターゲットは TDDを誤解している人 TDDハンズオン勉強会を弊社でもやろう!とか思ってる人 を想定していますっ。 誤解されがちなTDD、記事にするには書ききれないTDD...なるべく小難しい内容は省いて興味を持ってもらうための記事を書いてみようと思います! テスト駆動開発(TDD)は良い物だ! テスト駆動開発(TDD)とは何か? TDDに対する誤解 TDDハンズオンについて TDDハンズオンの趣旨 TDDハンズオンの計画 事前準備 スケジュールと概要 TDDハンズ

    テスト駆動開発(TDD)ハンズオンのすすめ - RAKUS Developers Blog | ラクス エンジニアブログ
  • 第4回 テストダブル ~忠実性と決定性のトレードオフを理解する~ | gihyo.jp

    自動テストを書く際に使いどころをマスターしたいテクニックがテストダブル(Test Double)です。テストダブルを効果的に使えばテストの網羅性、速度、再現性を向上させますが、使いどころを誤れば変更や改善の妨げになりかねません。今回は、テストダブルの利点と注意点をまとめます。 テストダブルとは何か テストダブルとは、自動テストに使用する偽物、代用品のことです。たとえば、データベースや外部サービスの動作を模倣した偽物(テストダブル)を作り、自動テストから使います。 自動テストで偽物を活用するテクニックを「モック」(⁠Mock)と呼ぶ方も多いですが、より正確には、テストに偽物を使う技術を総称してテストダブルと呼びます。この場合の「ダブル」は身代わりや影武者のようなイメージでとらえてください。テストに使う身代わりなのでテストダブルです。テストダブルの種類として詳しくはスタブ(Stub⁠)⁠、スパ

    第4回 テストダブル ~忠実性と決定性のトレードオフを理解する~ | gihyo.jp
  • 過度なDRYは読みやすさの敵!?「リーダブルテストコード」という発表をしました #vstat - give IT a try

    先日、このブログでもお伝えしましたが、「VeriServe Test Automation Talk No.3」というオンラインイベントで登壇してきました。 veriserve-event.connpass.com 申込者数はなんと1000人を超えていて、大変驚きました。 僕は「リーダブルテストコード」というテーマで発表しました。スライドはこちらです。 Twitterでたくさんシェアされたり、はてなブックマークがたくさん付いたり、こちらもすごい反響でビックリしました。 で、どんな内容だったの? ひとことで言うなら「テストコードを徹底的にDRYにしようとしちゃダメよ!」というお話です。 このネタは昔からQiitaやTwitterとかでことあるごとに話してきましたが、この勉強会であらためてなぜダメなのか、DRYに書かず、どう書くべきなのか、という話を力説してみました。 優秀なプログラマほど、「

    過度なDRYは読みやすさの敵!?「リーダブルテストコード」という発表をしました #vstat - give IT a try
  • テスト駆動開発(TDD)のゴール「動作するきれいなコード」について考えてみる - やっとむでぽん

    「偉大な書籍は偉大な出だしで始まる。ケント・ベック著『テスト駆動開発』(2003, 2017)はこう始まります。 「動作するきれいなコード」。Ron Jeffriesのこの簡潔な言葉が、テスト駆動開発(TDD)のゴールだ。 」 テスト駆動開発エバンジェリストとして活躍している、和田卓人さん(t_wada)の講演より引用 セミナー講師やアジャイルコーチの立場で、私もTDDを教えることがよくあります。そんなときはこの言葉を意識しつつ、TDDはあくまでスキル、手法のひとつに過ぎず、当に求めるべきは動作するきれいなコードなのだと、伝えるようにしています。そのことを説明する補助として、こんな図を作りました。 絵を描いてみて気づいたのですが、「動作する(Works)」には2つの側面があります。書いたコードが、書いたつもりの通りに動くこと(Verification)と、期待に応えて働き実際に役立つこと

    テスト駆動開発(TDD)のゴール「動作するきれいなコード」について考えてみる - やっとむでぽん
  • プログラミングで「もっと早く知っておけば良かった」と思う知識はなんですか?

    回答 (3件中の1件目) TDD(テスト駆動開発)。すなわち、テストコードを書き、実行して失敗し、それが成功するコード実装を書き、テストを成功させる。そして、リファクタリングをする。 こうすることで、(テストが正しく定義・実装されていることが前提ですが)コードの正しさは保証されますし、根拠のある自信を持てます。また、常にリファクタリングされているためクリーン・コードを保つことができ、機能追加や拡張をし易くなります。そのため、ビジネスのスピードを落とさず、継続的に成長させることが可能になります。 なぜ「TDDをもっと早く知っておけば良かった」のか。その感覚を掴んでいただくために、TDD...

    プログラミングで「もっと早く知っておけば良かった」と思う知識はなんですか?
  • 質とスピード(2020秋100分拡大版) / Quality and Speed 2020 Autumn Edition

    質とスピード(2020秋100分拡大版) 2020/11/20 @ JaSST'20 Kyushu

    質とスピード(2020秋100分拡大版) / Quality and Speed 2020 Autumn Edition
  • フロントエンドの負債と向き合う - mizchi's blog

    某所で書いたものを公開用に書き直したもの 前提 フロントエンドでTDDは難しい、というかほぼ不可能である。なぜなら事前に副作用をデータとして表現できるか不明だからだ。たとえばあなたのプロダクトの画面の何処かにボタンを追加するために、その内部表現を事前に思い浮かべることが可能だろうか? react-redux などのFluxフレームワークは如何に副作用をアクションとして表現することで、テスト・デバッグのための情報を残すか、という視点で発展してきた側面がある。あの冗長なアクション定義は、全てデバッグのために書いていると言っても、過言ではない。それすら「Textは文字がある」といったトートロジーなデータになりがち。 フロントエンドの現実的な単体テストは、他の開発者のために、自分が書いたコードの要求を満たしているか検知する手段として、防衛的にテストアフターしておく。これぐらいしか現実的な手法がない

    フロントエンドの負債と向き合う - mizchi's blog
    yuki_2021
    yuki_2021 2018/03/14
    陶芸家が泥を捏ねるようなものだ。
  • テスト駆動開発/振る舞い駆動開発を始めるための基礎知識

    連載目次 2000年代初期に開発手法として確立された「テスト駆動開発」(Test Driven Development、以下「TDD」)は、その後10年もの間で普及が進み、今や珍しくない開発スタイルの1つとなっています。国内でも「アジャイルアカデミー」「TDD Boot Camp」などによる推進・普及活動が各地で活発化し、認知が広がってきました。 なおTDDは誕生からこれまでの間に、さまざまな工夫や実践上のノウハウが提唱されてきました。またTDDの普及に影響を受け、他のさまざまな「テストファースト」手法も台頭してきています。 稿では、そうしたTDDの発展や、振る舞い駆動開発(Behavior Driven Development、以下「BDD」)など他のテストファースト手法への展開についても解説します。 ※編集部注:ソフトウェアの「テスト」そのものの概要や種類について知りたい方は記事「J

    テスト駆動開発/振る舞い駆動開発を始めるための基礎知識
  • いつでも聞けるTDD入門 #TDDBC_NAGOYA

    2014/05/18 TDDBootCamp in Nagoya でkyon_mmが基調講演に使用したスライドです。org-mode -> reveal.js -> pdfで変換したのでアニメーションは切られています。BDDようそRead less

    いつでも聞けるTDD入門 #TDDBC_NAGOYA
  • 実践的な設計って、なんだろう?

    Devlove 名古屋 2014-5-18 DDD, Object Oriented Design, ドメイン駆動設計 オブジェクト指向設計Read less

    実践的な設計って、なんだろう?
  • 特集:PHPUnit3で始めるユニットテスト|gihyo.jp

    運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します⁠。個別にライセンスが設定されている記事等はそのライセンスに従います。

    特集:PHPUnit3で始めるユニットテスト|gihyo.jp
  • テストコードを書く文化を根付かせたい─和田卓人|【Tech総研】

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

  • いまだにユニットテストって受け入れられないんだろうな - 個人的なまとめ

    色んな所で「テスト(ここではユニットテスト)を書かないのは小学生までだよねー」とか、もっと汚い言葉で言われたりするけど、いまだにうちのチームでは自分だけしか書かない現状が悩ましい。 Jenkinsさんが激おこになっても誰も何も反応しない。 もちろん、全部が書けるとも思ってないので、自分が不安なところとか、変更が多く入りそうなところとかを中心に書くようにしてる。一種の精神安定剤みたいなもん。 あるとき、一緒に働いてるエンジニアさん(ここではAさんとしておこう)に「ここ難しそうだから、テスト書いたほうがいいですよ」って話をしたら、「じゃぁ、工数かかっちゃいますね」って言われて結局書いてなかったな。 そうだよ。ユニットテスト書いたら工数かかるよ。それは純然たる事実。でも、再利用できないチェックシートを作ってやるよりもいいと思うんだけどね。しかもこの前に見せてもらったこのチェックシートも運用レベル

    いまだにユニットテストって受け入れられないんだろうな - 個人的なまとめ
    yuki_2021
    yuki_2021 2013/10/09
    悩ましいよね。一人テストコードを書いてもプロジェクトで使ってくれないと効果はないんだよなぁ
  • InfoQ: TDDを根づかせる:導入の問題と解決策

    Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。このでは、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

    InfoQ: TDDを根づかせる:導入の問題と解決策
  • 1