testingタグのついたNyohoのブックマーク

「testing」のタグが付けられた記事は全部で295件あります。 testingと共に使われるタグには xcodeturnipEmacsgame など があります。 記事には 『【翻訳】テスト駆動開発の定義 - t-wadaのブログ』を含みます。

ブックマーク一覧

  • スはスペックのス~RSpecによるテスト駆動開発の実演~ - 角谷信太郎 (2/3)

    PostgreSQLユーザ会北海道支部/Ruby札幌合同セミナー 2008-02-16 mylist/5130382 プレゼン資料はこちら→http://kakutani.com/20080216.html#p01 前: sm2370458 次: sm2371011

    スはスペックのス~RSpecによるテスト駆動開発の実演~ - 角谷信太郎 (2/3)
  • 良いユニットテストを書こう

    Ebisu.mobile #8 登壇資料です。 https://hey.connpass.com/event/335971/

    良いユニットテストを書こう
    Nyoho
    Nyoho 2024/12/21
    「Ebisu.mobile #8 登壇資料です。」
  • 【t-wada】自動テストの「嘘」をなくし、望ましい比率に近づける方法【Developer eXperience Day 2024 レポート】 - レバテックLAB

    プログラマ、テスト駆動開発者 和田 卓人 学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒。執筆活動や講演、ハンズオンイベントなどを通じてテスト駆動開発を広めようと努力している。『プログラマが知るべき97のこと』(オライリージャパン、2010)監修。『SQLアンチパターン』(オライリージャパン、2013)監訳。『テスト駆動開発』(オーム社、2017)翻訳。『事業をエンジニアリングする技術者たち』(ラムダノート、2022)編者。テストライブラリ power-assert-js 作者。 日CTO協会が主催する、開発者体験をテーマとしたイベント「Developer eXperience Day 2024」が、7月16日、17日に開催されました。 レポートでは、7月16日に行われたt-wadaこと和田卓人氏のセッション「望ましい自動テストとは:どのようなテストが開発生産性と開

    【t-wada】自動テストの「嘘」をなくし、望ましい比率に近づける方法【Developer eXperience Day 2024 レポート】 - レバテックLAB
  • みんなでワイワイ「テスト駆動開発」の話をやる会 #techramen24conf

    TechRAMEN 2024 Conference の発表資料です https://fortee.jp/techramen-24-conf/proposal/15047b38-b193-4320-8078-f6487db0d63e

    みんなでワイワイ「テスト駆動開発」の話をやる会 #techramen24conf
  • 望ましい自動テストとは|どのようなテストが開発生産性と開発者体験を共に高めるのか - Tech Team Journal

    自動テストの重要性が広く認知されるようになった一方、自動テストの活用に課題を抱える組織も依然として多く見受けられます。 記事では『Developer eXperience Day 2024』(主催:日CTO協会)における和田卓人氏によるセッション「望ましい自動テストとは:どのようなテストが開発生産性と開発者体験を共に高めるのか」の内容をお届けします。 和田卓人氏 執筆活動や講演、ハンズオンイベントなどを通じて自動テストやテスト駆動開発を広めようと努力している。 『プログラマが知るべき97のこと』(オライリージャパン、2010)監修。『SQLアンチパターン』(オライリージャパン、2013)監訳。『テスト駆動開発』(オーム社、2017)翻訳。『事業をエンジニアリングする技術者たち』(ラムダノート、2022)編者。 なぜ自動化テストを書くのか 和田 卓人です。インターネット上ではt-wada

    望ましい自動テストとは|どのようなテストが開発生産性と開発者体験を共に高めるのか - Tech Team Journal
  • ユニットテストってもう言わない! CI/CD時代のテスト分類に最適なテストサイズという考え方

    はじめに 以前からユニットテスト/単体テストという言葉は使いづらい、と感じており今回も旧Twitterで「テストを実行時間ベースで分類する良い言葉ないかなー」と呟いていたところ、「テストサイズのSMLって考え方があるよ」と教えて戴きました。 だいたいは教えてもらったt_wadaさんの記事にすべて書いてあるのですが、自分の整理も含めて動画にしたので、その補完記事となります。 TL;DR 単体テストのバベルの塔は既に崩壊 CI/CDでの継続的テストには時間ベースのテスト分類が重要 UT/IT/E2EではなくSMLによるテストサイズがCI/CDには合う それは単体テストか結合テストなのか? 自動テスト、手動テストに関わらずテストの分類として単体テストと結合テストという言葉は一般的です。 ITQBではTest Levelsという言葉で定義されていますし、以下のようなV字モデルの対応表はみんな知って

    ユニットテストってもう言わない! CI/CD時代のテスト分類に最適なテストサイズという考え方
  • power-assert-monorepo/packages/node at main · twada/power-assert-monorepo

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    power-assert-monorepo/packages/node at main · twada/power-assert-monorepo
  • System tests have failed

    When we introduced a default setup for system tests in Rails 5.1 back in 2016, I had high hopes. In theory, system tests, which drive a headless browser through your actual interface, offer greater confidence that the entire machine is working as it ought. And because it runs in a black-box fashion, it should be more resilient to implementation changes. But I'm sad to report that I have not found

    System tests have failed
  • 【翻訳】テスト駆動開発の定義 - t-wadaのブログ

    このブログエントリでは、テスト駆動開発(TDD: Test-Driven Development)の考案者Kent BeckがTDDの定義を改めて明確化した文章を、許可を得たうえで翻訳し、訳者の考察を沿えています。 きっかけ 2023年の年末、テスト駆動開発(TDD: Test-Driven Development)の考案者Kent Beckは、あらたな著書『Tidy First?』の執筆にあたり、substackにTDDに関するポストを連投して論戦を繰り広げていました。TDDはその誕生から20年以上が経ち、その間に「意味の希薄化」が発生して議論が噛み合わなくなっていました。意味の希薄化(Semantic Diffusion)とは、新しく作り出された用語が広まる際に来の意味や定義が弱まって伝わる現象です。 私(和田)はTDDと関わりの深いキャリアを歩んできました。Kent Beckの著書

    【翻訳】テスト駆動開発の定義 - t-wadaのブログ
  • テストの学習へようこそ!  |  web.dev

    テストの学習へようこそ! コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 このコースでは、ウェブ用のテストの概要と探索について説明します。 このコースで学習する内容は次のとおりです。 テストの基礎 自動テストと手動テスト テストを実施する場所と方法 ベスト プラクティス 何をテストすべきか、誰に責任があるのか、目的そのものとしてではなく、目的を達成するために手段をテストすることを検討する方法など、テストの理念。 このコースには、学習に役立つ簡潔で実用的なサンプルコードも含まれています。 コースのスコープには、Node.js などの環境で実行される、フロントエンドJavaScript とドキュメント モデル、バックエンドでのライブラリ テストが含まれます。テストの経験はありませんが、JavaScript の基礎知識と Node.js などに関する経験が必

    テストの学習へようこそ!  |  web.dev
  • 保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ~Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より | gihyo.jp

    『Software Design』連動企画 保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発⁠⁠、その全体像 ~Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より 今回、Software Design 2022年3月号 第2特集「そろそろはじめるテスト駆動開発 JavaScriptでテストファーストに挑戦」の第1章「保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像」をサイトに掲載します。第2章以降については、誌『Software Design 2022年3月号』電子版(Gihyo Digital Publishing、Amazon Kindle)をご購読いただければ幸いです。 第1章では、混同されることの多い自動テスト関係の概念を、自動テスト、テストファースト、テスト駆動開発の3つの段階に分

    保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ~Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より | gihyo.jp
  • サバンナ便り ~ソフトウェア開発の荒野を生き抜く~ 記事一覧 | gihyo.jp

    第7回テストコードの認知負荷 ~テストの名前⁠⁠、構造⁠⁠、情報量を工夫する~ 和田卓人 2023-08-22

    サバンナ便り ~ソフトウェア開発の荒野を生き抜く~ 記事一覧 | gihyo.jp
  • 実録レガシーコード改善 / Working with Legacy Code: the True Record

    2024/01/15(月) 12:00 〜 13:00 t-wadaさんが後世に残したい、実録レガシーコード改善 https://findy.connpass.com/event/304101/ テストコードが無いコードを引き継いだところからはじまる、実際に2018年に行った受託開発案件のエ…

    実録レガシーコード改善 / Working with Legacy Code: the True Record
    Nyoho
    Nyoho 2024/01/16
    t-wadaさんのリファクタリング内容の講演すごい
  • 結合テストを書くときはコードベースを分離している

    新規開発の設計支援や古いコードベースを甦らせて欲しいという相談をもらったときに、最初にちょろっとコードだけお手的なコードを書いてから引き渡しているのだが、そのときに必ず結合テストを書くようにしている。 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さ

    2023年 新卒研修② エンジニア・デザイナーが合同でモノづくりを学ぶ テスト駆動開発(TDD)編
  • 自動テスト全体の信頼性を維持するためにはどうするか 「ブレない基準でピラミッドを作り、スモールに切り出していく」 | ログミーBusiness

    テスト用に使う偽物「テストダブル」和田卓人氏:じゃあ次。テストダブルの話にいきます。「忠実性と決定性のトレードオフを理解しよう」という点です。これはもうちょっとあとにまた出てきます。 テストダブルというもので、モックオブジェクトとかスタブとかを使って、物ではない偽物をテスト用に使ってテストをすることはよくありますよね。 データベースの偽物とか外部システムの偽物とか、AmazonのS3の偽物とか。物を使えない、あるいは使いたくないからテスト用の偽物で置き換えるということをよくやります。 こういう、テスト用に使う偽物のことを総称して「テストダブル」と呼びます。テスト用の偽物を何と呼ぶかは混乱しきっていた歴史があります。ある人はこういうテスト用の偽物のことを「モック」と呼んで、ある人は「フェイク」と呼んで、ある人は別の呼び方をしてみたいな感じになっちゃうんですね。ある人が「スタブ」と言ってい

    自動テスト全体の信頼性を維持するためにはどうするか 「ブレない基準でピラミッドを作り、スモールに切り出していく」 | ログミーBusiness
  • ジョブを細かく分けてGitHub Actionsのテストを効率化する

    改善戦略 実行のタイミングやGitHubの状況や依存サーバーのネットワークの状況によって変動はあるものの、早くて7分、だいたい10分〜15分くらいかかっている。早いか遅いかは、他の開発と比べても内容や状況が違うのでなんとも言い難いが、個人的な感想としては「遅い」。というより、一切の工夫をしていなかったので、もっと早くできるはずだと考えた。 ビルドされたファイルを複数の環境で共有する 処理全体の中で時間がかかっている処理は3つ。 依存パッケージのインストール ビルド テスト さらに、課題の一つとして「テスト実行時に開発用依存パッケージ(devDependencies)がインストールされているせいでテストが失敗しない問題がある」というものがあり、これを処理に追加しないといけない。 開発用依存パッケージのインストール ビルド 依存パッケージを一旦すべて削除 番用依存パッケージのインストール テ

    ジョブを細かく分けてGitHub Actionsのテストを効率化する
    Nyoho
    Nyoho 2023/05/07
    “Jestのshardという機能で、CIのための分割機能だ。これ考え人天才かよ。”
  • 滑らかなDevOpsを実現するE2Eテストの構築と運用

    はじめに 「HRMOS タレントマネジメント」(以下、「HRMOS」)では1年間かけて、自動 E2E テストの導入から開発・運用をしてきました。 最終的には、画像のように ChatOps でいつでも簡単に開発者が E2E テストを実行できる環境が整備されました。 この記事では、1年間で溜まった知見をもとに主に以下の内容に触れていきます。 「HRMOS」における自動 E2E テストの導入の理由 自動 E2E テスト(Autify)の導入までの道筋 自動 E2E テストの DevOps 連携 自動 E2E テストの活用による品質担保 自動 E2E テストの導入や、その活用法に悩んでいる方の助けになれば幸いです。 「HRMOS」における自動 E2E テストの必要性 「HRMOS」では日々ユニットテスト、インテグレーションテストなどの様々なテストが CI で動いています。 加えて、開発者も bra

    滑らかなDevOpsを実現するE2Eテストの構築と運用
  • なぜテストコードを書くのだろう? - Uzabase for Engineers

    こんにちは、NewsPicksの北見です。 ところで皆様、テストコードって書いてますか...? ネットでテストコードについて検索すると 「テストコードを書きましょう」 「テストコードとはこうあるべし」 「TDD(Test Driven Development)だ」 等々が叫ばれています。 ただ、なんとなく「方法論ありきでとにかくテストを書け」と言われているようで、テストの必要性について納得感に欠けている方もいらっしゃるのではないでしょうか? なぜ テストコードを書くのでしょうか? テストコードを書く理由 将来リファクタリングをしやすくする テストコード書く途中で、開発者自身が仕様を理解し、成長できる 最後に テストコードを書く理由 諸説ありますが、私が思うテストコードを書く理由は 将来リファクタリングをしやすくする テストコード書く途中で、開発者自身が仕様を理解し、成長できる の2つです。

    なぜテストコードを書くのだろう? - Uzabase for Engineers
  • testing-library でユーザの気持ちになって書くフロントエンドのテスト

    TL;DR フロントエンドのテストが壊れやすく要因の一つは、ユーザがどのようにソフトウェアを使うかをクエリに反映できていないからかも testing-library はソフトウェアを使うユーザの気持ちを反映させやすいようにクエリの優先度をつけていて、それに従うほうがいい 優先度の低いクエリも役に立つことがある 運用しているアクセシビリティなどの実装のガイドラインに沿うようなテストを作るとき アクセシビリティの低い実装をリファクタリングするためのテストを作るとき はじめに フロントエンドのテストに用いるツールとして testing-library が知られています。testing-library は提供しているクエリに優先度をつけています。この優先度は、どういう基準でつけられているのでしょうか。 この記事では、 testing-library のガイドを読みながら、クエリの優先度を「ユーザの

    testing-library でユーザの気持ちになって書くフロントエンドのテスト