t-wada氏に聞く、テストを書き始めるための「はじめの一歩」 - レバテックラボ（レバテックLAB）
プログラマ、テスト駆動開発者 和田卓人 学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒。執筆活動や講演、ハンズオンイベントなどを通じてテスト駆動開発を広めようと努力している。『プログラマが知るべき97のこと』（オライリージャパン、2010）監修。『SQLアンチパターン』（オライリージャパン、2013）監訳。『テスト駆動開発』（オーム社、2017）翻訳。『事業をエンジニアリングする技術者たち』（ラムダノート、2022）編者。テストライブラリ power-assert-js 作者。 講演や執筆などを通じ、日本におけるテスト駆動開発のエバンジェリストとして知られる和田卓人さん。 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の正
TDD(テスト駆動開発)をするぞという強い気持ちをもって新訳「テスト駆動開発」を読んでいるお話 - Qiita
はじめに Ateam Hikkoshi Samurai Inc. Advent Calendar 2017の13日目です。 本日はエイチーム引越し侍の今年5月入社のRubyist、 @ex_SOUL が担当します。 背景: なぜTDDについて書こうと思ったのか 以前、CodeRetreatイベントに参加した際、周りのRubyistが当たり前のようにテストを書いていたため、このままではいけない…！という危機感を持ったことが始まりでした。 そして先日新訳版の「テスト駆動開発」を購入しました。 翻訳に和田卓人さん( @t_wada ) が携わった本です。 @t_wada さんといえば、以下のイメージで有名だと思います。 ※上記画像はここで言及されている通りライセンスはパブリックドメインです。感謝 「TDDは死んだ」のか TDDでGoogle検索を実施すると、TDDを薦める記事、逆にTDDは死んだ
テスト駆動開発(TDD)って何? - Qiita
はじめに 実務においてテスト駆動開発でシステム設計を行うことがなかったので、学習の一環としてまとめます。 調べる前は、「テストする前にテストコードを書くくらい」といった印象。 テスト駆動開発とは? テスト駆動開発（Test-Driven Development）の略称としてTDDと呼ばれています。 テストファーストの思考に基づく開発手法の一つで、ウォータフォールでよくある「設計→実装→テスト」のプロセスではなく、「テスト→実装→リファクタリング」 といった流れを何度も繰り返ししてプロダクトを成長させていくような開発手法です。 テスト駆動開発は、「レッド」「グリーン」「リファクタリング」のステップで構成されています。 【レッド】実装した機能の要件をもとに失敗するテストコードを書く テスト駆動開発では「必ず失敗するコードを書く」、つまり、実装したい機能を実現するコードが一切書かれていない場合で
書評：GitHub Copilot とのペアプロ TDD でつくるローグライク RPG - 若くない何かの悩み
本記事は「GitHub Copilot とのペアプロ TDD でつくるローグライク RPG」の書評です。題名にローグライクRPGとあるのでゲーム開発の本なのかなと思ってしまいますが、本題は仕様の端的な表現をもたないシステムを LLM を使って真っ当に開発する方法の解説だと思います。タイトルにローグライクRPGと書いていることでゲーム開発に興味のない人の興味を失わせてしまい損をしている気がします。 背景 最近の LLM の流行を受けて私も Chat-GPT や GitHub Copilot といった LLM を開発で利用しています。端的に仕様を表現できるシステムは LLM に質問して実装を得る方が自分で実装するより圧倒的に速く正確であるという感想を抱いています。ただ端的に仕様を表現できるシステムばかりではありません。えてして価値を生んでいるシステムというのは端的な仕様の表現が存在しないもので
テスト駆動開発のはじめの一歩｜t_wadaさんに聞く1人で始める自動テストのコツと考え方 - Agile Journey
アジャイル型の開発が導入されていない現場であっても、そして一人であっても、実践可能なアジャイルに関するプラクティスは存在します。 例えば、自動テストや、テストファースト、テスト駆動開発（TDD：Test Driven Development）です。ユニットテストフレームワークを使ってテストコードを書いて開発しながらテストを実行する「自動テスト」、実装の前にそのテストコードを書く「テストファースト」、テストと実装を繰り返しながらインクリメンタルに設計・開発を行うのが「TDD」。これらプラクティスのなかで、はじめの一歩となるのが自動テストですが、1人で実践するには、どこからはじめるか、どうテストを組み立てればよいのか、あるいは自分のテスト方法は適切なのか、不安を持つこともあるでしょう。 そこで本稿では、さまざまなチームや組織へのテスト手法の導入を支援し、精力的に講演や執筆などを行ってきたこの分
twadaさんによる2023年度版TDDワークショップを開催しました - Pepabo Tech Portal
挨拶 こんにちは。2023年04月に入社した、minne事業部エンジニアの@kazuです。 この度、弊社GMO ペパボ(以下、ペパボ)では2022年に引き続き、今年も日本のTest-Driven Development(TDD) の第一人者である @t_wada さんをお招きしてTDDワークショップを開催しました。前回：『t_wadaさんによるTDDワークショップを開催しました』 なぜTDDワークショップを開催しているのかについては、こちらの記事『ふつうの開発と TDD ワークショップ』で詳しく説明していますのでご覧ください。 さて、それでは今回のTDDワークショップで何をしたのか、どんな気づきがあったのかなどについて、参加パートナーからそれぞれお話ししてまいります。 具体的な研修内容 概要 ワークショップは、事前に各参加パートナーが基調講演/ライブコーディングの動画を予習し、動画内でのラ
@t_wadaに学ぶテスト駆動開発【CARTA 23新卒研修】 - CARTA TECH BLOG
こんにちは！CARTA 技術広報の@ShuzoNです。 @t_wadaさんによるテスト駆動開発の研修を行いました @t_wadaによる 「みてわかるテスト駆動開発」 4/12(水)、 CARTAの技術顧問である@t_wadaさんを招聘し、テスト駆動開発（TDD: Test-Driven Development )研修を行いました。 テスト駆動開発とは テスト駆動開発とは、開発時にコードの検証を小さく重ねフィードバックを得ながら進めるプログラミング開発手法です。これにより大きな問題を小さな問題に分割し、漸進的に安心しながらコードの改善を進めることが出来ます。 具体的には、最初に実コードに期待する振る舞いをテストするコード(テストコード)を書き、そのテストコードが成功するように実コードを連続的にリファクタリングしていきます。結果的には、テストコードが実コードの振る舞いを担保してくれるため、自分
フロントエンドのテストコードを書くときに大切にしていること - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、フロントエンドエキスパートチームの @mugi_unoです！ kintone では フロントエンドの刷新プロジェクト（通称フロリア）が進行中です。 blog.cybozu.io kintone の開発では E2E 主体の自動テストを整備していましたが、 フロントエンドの刷新に合わせて、新たにフロントエンド側でのテストコードを積極的に書いています。 テストを書くことに不慣れなメンバーもいるため、日々 Pull Request 上でのレビューやペア・モブ作業を通じて、知見の共有が行われています。今回はフロントエンド刷新のテストを書いてきた中から、筆者が有用だと感じた知見やノウハウを紹介したいと思います。 目次 💡「実はそれ最初からパスしてるかもしれない」 期待する操作で期待する結果になることを厳密に検証する 他のテストケースによって前提条件を担保する 💡「テストコード上のロジッ
TDDが必要なのはどんな時？新人の質問からテスト駆動開発の理解を深める - BIGLOBE Style ｜ BIGLOBEの「はたらく人」と「トガッた技術」
開発部門（基盤本部）でエンジニアの育成を担当している高玉です。 BIGLOBEでは週に1日、集合型の新人エンジニア研修を開催しています。インターネットに公開された教育コンテンツを活用しながら、手を動かして学ぶ（Learn by doing）が特長です。 style.biglobe.co.jp 研修の後に必ずアンケートに回答してもらっているのですが、新人ならではの質問をもらえるのがいつも楽しみです。 さて、テスト駆動開発（Test Driven Development：TDD）について学んだ後にもらったのが、次の質問です。 Q 仕様がコロコロ変わるケースや、コードを触りながらわかっていくような非機能要件などには適用できなさそうだと思いました。どういったケースにTDDが用いられるのでしょうか。逆にどういったケースには向かないのでしょうか？ 研修の様子をお伝えするために、この質問にどう回答したの
“オブジェクト指向”と“テスト駆動開発”は非常に相性がいい 2010年前半におきたツールのムーブメント
受け入れテスト駆動開発（ATDD）が2013年からどのように変化してきたかについて、デロイトトーマツコンサルティング合同会社執行役員のkyon_mm氏とBASE BANK株式会社テックリード兼マネージャーの東口氏がトークをしました。全4回。1回目は、ATDDの歴史とkyon_mm氏の試みについて。 ATDDについて8年越しのリプライ kyon_mm氏（以下、キョン）：今日のイベントについて説明します。みなさんconnpassでお集まりいただいたと思うんですが、1990年代に広まりはじめたTDD（テスト駆動開発）について、2013年くらいに私がちょっと話をしました。 先日、日本でも有数の優秀なエンジニアたちが集ってプレゼンテーションする「July Tech Festa」というカンファレンスの中で、東口さんがATDD（受け入れテスト駆動開発）のプレゼンテーションをしていたんですね。そのときに私
「テスト書いてないとかお前それ〜」が私の代名詞になるまで。テスト駆動開発とともに歩んだキャリア - Findy Engineer Lab
日本におけるテスト駆動開発の著名人といえば誰か？ この問いを投げかけられたとき、多くのエンジニアが思い浮かべる人物がいます。ITコンサルタント・ソフトウェアエンジニアの和田卓人（@t_wada）さんです。和田さんは日本のテスト駆動開発の第一人者として、長年、この分野の実践や講演・執筆などの普及活動を続けてきました。 こう書くと、読者のなかには「和田さんはもともとテストが好きだったから、テスト駆動開発の第一人者になれたのでは」と思われた方もいるかもしれません。しかし、その答えはNOです。むしろ和田さんは、テストが嫌いなエンジニアだったといいます。ある出来事をきっかけとして、嫌いだったテストを好きになれる方法を見つけたのです。 読者の方々にも「自分には○○なんて向いていない」という印象を抱いている技術領域があるかもしれません。ですが、そんな領域にこそ、あなたの新たな可能性が詰まっているかもしれ
スピード感重視なのでテストは書かない。テストはなぜ開発を遅くするか - Qiita
あまりにバズってしまったので、前書きを追加 ここまでバズってしまって正直すまんかった。 この記事はもともと愚痴記事をマイルドにして投稿しただけなので「テストを勧める」とか「テストを信奉する」とかそこまで強い意図は特にありません。（私がテスト好きなのは否定しません） 「テスト書こう」に対して「そんなコストはない」と言いながら、いろいろ問題が生じる現状を愚痴りたかっただけです。愚痴るだけだと生産性がないから、なんでこんなに認識が違うんだろうと原因を考えた結果、テストを書くことに対する技術で実際にコストが大きく異なるなと気づいて書いた次第です。 この記事の対象は「テストを書く技術がなく、テストを書く気がない」組織に所属する人です。 アジャイル開発において「テストコードは当然」なのか？という記事で（私の記事をきっかけとして）テストコードの「徹底」とか「カバレッジ100%」とかを批判し、トレードオフ
テスト駆動開発を読んで / fujimisakari blog
自分はTDDについての知識は、ネット上の誰かの記事でつまみ読み程度でこうした本を読んで勉強するのは初めてでした。そして、普段の開発でテストを書いてるかというとそんなに書いてなく必要に応じて書く感じでした。率先して書いてなかった理由としてあまりテストの知識を持ってなく勉強してキレイなテストを書けるようになってからっと思ってたので、時が来たって感じでた。 読んでみると最初にすごくビックリしたのがTDDの概念を誤認してたことです。まずテストを書いて開発を進めるテストファーストな開発方法がTDDと思ってたのですがそれは間違いでした。TDDは開発者が設計の治具としてテストコードを同時に書きながら開発と改善を回していくのが目的でした。なので、この本にはテストとリファクタを回しながらどうやって動作するキレイなコードになるかまでが書かれています。 コードの設計やロジックを美しく書くことは日々意識してますが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
