【翻訳】テスト駆動開発の定義 - 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の正
テストの学習へようこそ！ | web.dev
テストの学習へようこそ！ コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 このコースでは、ウェブ用のテストの概要と探索について説明します。 このコースで学習する内容は次のとおりです。 テストの基礎 自動テストと手動テスト テストを実施する場所と方法 ベスト プラクティス 何をテストすべきか、誰に責任があるのか、目的そのものとしてではなく、目的を達成するために手段をテストすることを検討する方法など、テストの理念。 このコースには、学習に役立つ簡潔で実用的なサンプルコードも含まれています。 コースのスコープには、Node.js などの環境で実行される、フロントエンドの JavaScript とドキュメント モデル、バックエンドでのライブラリ テストが含まれます。テストの経験はありませんが、JavaScript の基礎知識と Node.js などに関する経験が必
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より | gihyo.jp
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より 今回、Software Design 2022年3月号 第2特集「そろそろはじめるテスト駆動開発 JavaScriptでテストファーストに挑戦」の第1章「保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像」を本サイトに掲載します。第2章以降については、本誌『Software Design 2022年3月号』電子版（Gihyo Digital Publishing、Amazon Kindle）をご購読いただければ幸いです。 第1章では、混同されることの多い自動テスト関係の概念を、自動テスト、テストファースト、テスト駆動開発の3つの段階に分け、それぞれの効果や注意点を説明します。ソフ
サバンナ便り ～ソフトウェア開発の荒野を生き抜く～ 記事一覧 | gihyo.jp
第7回テストコードの認知負荷 ～テストの名前、構造、情報量を工夫する～ 和田卓人 2023-08-22
結合テストを書くときはコードベースを分離している
新規開発の設計支援や古いコードベースを甦らせて欲しいという相談をもらったときに、最初にちょろっとコードだけお手本的なコードを書いてから引き渡しているのだが、そのときに必ず結合テストを書くようにしている。 3, 4年前から僕と付き合いがある人からすると、 「「「あの sadnessOjisan がテストを書くだと！！！」」」 という感じだと思うのだが、最近はテストに思うところもあってちゃんと書いている。 そしてそのテストコードだが、基本的にはアプリケーションから分離して書いている。その話をしたい。 OGP OGP は野方ホープで海苔が分離されて出てきた時の画像だ。 アプリケーションから分離したテストとはどういうことか 最終的にはテスト対象のサーバーを Docker コンテナで固めて、そのコンテナに対して HTTP リクエストを投げてその結果や DB の中身を検証するコンテナを docker
2023年 新卒研修② エンジニア・デザイナーが合同でモノづくりを学ぶ テスト駆動開発（TDD）編
Visionalグループ 株式会社ビズリーチでは、2023年4月に入社した新卒プロダクト職（エンジニア/デザイナー）を対象とした新卒研修を約3ヶ月の間実施しました。最初の約1ヶ月間はビジネス職と合同で顧客志向を中心に学び、その後はプロダクト職としてモノづくりのプロセスや品質の基礎を学びました。 研修を通して得た学びや変化について、受講した社員が3回にわたりご紹介します。 本記事では、テスト駆動開発（TDD）の日本での第一人者として知られる和田卓人(@t_wada)さんを講師としてお招きし、品質の大切さを学んだ「TDDワークショップ」について、プロダクト職（エンジニア）の渋谷がお伝えします。 TDDワークショップの概要 ワークショップの構成 TDDとはプログラム実装前にテストコードを書き、そのテストに適合するようにコードを実装する開発手法です。今回のTDDワークショップでは、@t_wadaさ
自動テスト全体の信頼性を維持するためにはどうするか 「ブレない基準でピラミッドを作り、スモールに切り出していく」
Qiita Conferenceは、ソフトウェア開発者が集まり、最新の技術や最先端の挑戦・ソフトウェアの未来についての考えや知見を共有し、つながる場を創出する、「Qiita」が開催するオンライン技術カンファレンスです。ここで和田卓人氏が「サバンナ便り - 自動テストに関する連載で得られた知見のまとめ（2023年5月版） 」をテーマに登壇。最後に、テストダブルとテストピラミッド、サイズダウン戦略について話します。 テスト用に使う偽物「テストダブル」 和田卓人氏：じゃあ次。テストダブルの話にいきます。「忠実性と決定性のトレードオフを理解しよう」という点です。これはもうちょっとあとにまた出てきます。 テストダブルというもので、モックオブジェクトとかスタブとかを使って、本物ではない偽物をテスト用に使ってテストをすることはよくありますよね。 データベースの偽物とか外部システムの偽物とか、Amazon
ジョブを細かく分けてGitHub Actionsのテストを効率化する
改善戦略 実行のタイミングやGitHubの状況や依存サーバーのネットワークの状況によって変動はあるものの、早くて7分、だいたい10分〜15分くらいかかっている。早いか遅いかは、他の開発と比べても内容や状況が違うのでなんとも言い難いが、個人的な感想としては「遅い」。というより、一切の工夫をしていなかったので、もっと早くできるはずだと考えた。 ビルドされたファイルを複数の環境で共有する 処理全体の中で時間がかかっている処理は3つ。 依存パッケージのインストール ビルド テスト さらに、課題の一つとして「テスト実行時に開発用依存パッケージ（devDependencies）がインストールされているせいでテストが失敗しない問題がある」というものがあり、これを処理に追加しないといけない。 開発用依存パッケージのインストール ビルド 依存パッケージを一旦すべて削除 本番用依存パッケージのインストール テ
滑らかなDevOpsを実現するE2Eテストの構築と運用
はじめに 「HRMOS タレントマネジメント」（以下、「HRMOS」）では1年間かけて、自動 E2E テストの導入から開発・運用をしてきました。 最終的には、画像のように ChatOps でいつでも簡単に開発者が E2E テストを実行できる環境が整備されました。 この記事では、1年間で溜まった知見をもとに主に以下の内容に触れていきます。 「HRMOS」における自動 E2E テストの導入の理由 自動 E2E テスト（Autify）の導入までの道筋 自動 E2E テストの DevOps 連携 自動 E2E テストの活用による品質担保 自動 E2E テストの導入や、その活用法に悩んでいる方の助けになれば幸いです。 「HRMOS」における自動 E2E テストの必要性 「HRMOS」では日々ユニットテスト、インテグレーションテストなどの様々なテストが CI で動いています。 加えて、開発者も bra
なぜテストコードを書くのだろう? - Uzabase for Engineers
こんにちは、NewsPicksの北見です。 ところで皆様、テストコードって書いてますか...? ネットでテストコードについて検索すると 「テストコードを書きましょう」 「テストコードとはこうあるべし」 「TDD(Test Driven Development)だ」 等々が叫ばれています。 ただ、なんとなく「方法論ありきでとにかくテストを書け」と言われているようで、テストの必要性について納得感に欠けている方もいらっしゃるのではないでしょうか? なぜ テストコードを書くのでしょうか? テストコードを書く理由 将来リファクタリングをしやすくする テストコード書く途中で、開発者自身が仕様を理解し、成長できる 最後に テストコードを書く理由 諸説ありますが、私が思うテストコードを書く理由は 将来リファクタリングをしやすくする テストコード書く途中で、開発者自身が仕様を理解し、成長できる の2つです。
testing-library でユーザの気持ちになって書くフロントエンドのテスト
TL;DR フロントエンドのテストが壊れやすく要因の一つは、ユーザがどのようにソフトウェアを使うかをクエリに反映できていないからかも testing-library はソフトウェアを使うユーザの気持ちを反映させやすいようにクエリの優先度をつけていて、それに従うほうがいい 優先度の低いクエリも役に立つことがある 運用しているアクセシビリティなどの実装のガイドラインに沿うようなテストを作るとき アクセシビリティの低い実装をリファクタリングするためのテストを作るとき はじめに フロントエンドのテストに用いるツールとして testing-library が知られています。testing-library は提供しているクエリに優先度をつけています。この優先度は、どういう基準でつけられているのでしょうか。 この記事では、 testing-library のガイドを読みながら、クエリの優先度を「ユーザの
雑に作って、それから作り込んで、最後にテストを書く「テストラスト」開発 - give IT a try
（この話は最初Twitterに書こうと思ったけど、長くなるのでブログに書くことにしました） 僕はRSpecやMinitestでテストを書くのは得意ですが、常にテストファースト（TDD）で開発するとは限りません。 今業務でやってるタスクはこんなふうに進めてます。 雑に動くものを作る ↓ 見た目をきれいにする＆機能を作り込む ↓ テストを書く ↓ リファクタリングする この順番で開発する理由を以下に述べます。 雑に動くものを最初に作る理由 最初は見た目とか、異常系とか、細かい仕様とかを無視して、正常系が一通り動くものを作ります。 これはこれから作ろうとしているものの認識が合っているかどうかをPO（プロダクトオーナー）に確認するためです。 実際に動く画面を見せると「こんな感じでOK」とか「ここはこういうふうにしたい」というフィードバックをもらうことができます。 また、開発者としてもコードを書きな
DIP(依存性逆転の原則)を守っていない話
一昨日くらいに 「DIP してもどうせ辛くなるよね」的なことを適当にツイートしたら引用 RT や RT 後言及やエアリプで言及された上に「こいつは設計を何も理解しとらん」みたいなことを言われた。「俺は本当に何も理解していないのか？」と不安になったので、自分の考えをちゃんと書いておこうと思った。先に自分の立場を言うと、なんたらアーキテクチャとか SOLID 原則は有用だし自分も使うが、それを厳守しようとは思っていないと言う立場だ。 DIP とはなんだったか DIP(依存性逆転の原則)は SOLID 原則の一つで、一言で言うと「抽象に依存させると依存関係が逆転する」といったものだ。何のことやらという風になるので例だけ挙げると、UserRepository と UserService があってこのように定義すると class UserRepository { get() { return dat
t_wadaさんによるTDD研修をワードクラウド・名言5選で振り返ってみた - Link and Motivation Developers' Blog
（※以下は去年の弊社のQiita アドベントカレンダーに投稿したものです。） リンクアンドモチベーションで、QAエンジニアをしています、代慶と申します。 先日のレガシーコード改善のワークショップに引き続き、和田卓人（t_wada）さんにTDD（テスト駆動開発）に関してワークショップを開催してもらいました。 本記事では、t_wadaさんの頻出していた言葉や名言と共に、当日の研修での学びの概要を伝えていきたいと思います！ 当日の流れ 当日は、10人のエンジニアが10時から16時まで研修を受講しました。 前半は、座学メインで、適宜質問にも答えていただきました。 後半は、実習メインで、TDDの実践を行い、t_wadaさんとの公開1on1の時間を設けていただきました。 ※今回の講義は、前もってTDD Boot Campの動画の視聴も行い、よりTDDの理解を深めることができました。 TDDの概要 TD
【入門】フロントエンドのテスト手法まとめ - Qiita
はじめに 自分は2021年に新卒でweb系の開発会社にフロントエンジニアとして入社し2022年で2年目になります。 実務ではReact×TypeScriptを利用したフロント周りの開発をメインで行なっていなす。 今回は実務でNext.jsプロジェクトにテストを導入することになり「React-Testing-Library」と「Jest」について改めて学び直したのでその内容を紹介します。 はじめに「React-Testing-Library」と「Jest」の概要を説明しその上で具体的なテストコードを何パターンか書いていきます。 この記事の対象者 フロントエンドのテストの概要を知りたい人 React-Testing-LibraryとJestについて知りたい人 具体的なテストの書き方を学びたい人 なお本記事では、React-Testing-Libraryの具体的な書き方についてをメインにしている
Prisma で本物のDBMSを使って自動テストを書く - mizdra's blog
DBMS に依存するロジックのテストを書く時、主に2つの手法があると思います。 Repository 層などを mock する Service 層のテストをする時は、その下位の Repository 層を mock して、DBMS に依存しない形にしてからテストする レイヤードなアプリケーションで適用できる手法 テスト実行時も DBMS を裏で動かして、それを使う 本番と同じスキーマを持つ DBMS に対して、実際に insert したり select してテストする DBMS は docker-compose upとかで事前に立ち上げておく 双方にそれぞれ良さがあって、プロダクトによってどっちでやるか変わってくると思います。 この記事では 2 の手法を Prisma でどうやるかについて紹介します。 前提 実際のテストコードの例 テストヘルパーを作る 別解: ヘルパーを自動生成する je
t-wadaさん直伝・TDDワークショップを開催して、社内にテスト文化が芽生え始めた！ | PR TIMES 開発者ブログ
こんにちは、バックエンドエンジニアの江間です。 先日、テスト駆動開発（TDD）の日本での第一人者として知られる和田卓人(@t_wada)さんをお招きして、オンラインでテスト駆動開発ワークショップを開催しました。 抱えていた課題感 もともとPR TIMESには自動テストを書いていく文化がありませんでした。2022年初頭あたりから徐々に自動テストを追加するようになって来ましたが、テストを書く経験が浅いメンバーが多く、何となくテストコードを書いている状況でした。 メンバーとしては、テストを書こうとしても、何をテストすればいいのか？どうやって書いていけばいいのか？などが分かっておらず、テストを書くことへのスキル不足が課題となっていました。 また、 PHP のエキスパートとしてジョインしている uzulla さんが「テストの書けるコードがいいコード」と伝えてきましたが、テストの経験が浅いメンバーにと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
実録レガシーコード改善 / Working with Legacy Code: the True Record
デブサミ2023 / テストを学びたい開発者のためのソフトウェアテスト読書マップ / Software Testing Reading Map for Developers
新規アプリの単体テスト戦略 / unit_tests_strategy_of_new_app