テストコードにはテストの意図を込めよう #vstat
リーダブルなテストコードについて考えよう～VeriServe Test Automation Talk No.3～で発表した資料です。 【発表資料中のURL】 ※複数ページで出てくる場合は、初出のページ数に掲載 ◆P7 ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J03 ◆P17 リーダブルテストコード / #vstat ◆P43 見てわかるテスト駆動開発 ◆P46 JaSSTレポート（過去のJaSSTの講演資料などが載っています） ◆P47 Agile Testing Condensed Japanese Edition ◆P48 A Practical Guide to Testing in DevOps Japanese Edition ◆P49 The BDD Books - Discovery (Japa
Goのテスト安定性向上のためにFlakyなテストを再試行する機能を導入する提案 - tomato3713’s blog
Go言語にFlakyなテストへのサポートを追加する提案が面白かったので紹介します。 概要 Flakyなテストとは、コードに変更がないにもかかわらずテストが成功したり失敗したりと不安定な実行結果になるテストのことです。 テスト結果は本来なら全て成功ならリリース可能、1つでも失敗すればバグがあるのでリリース不可のようにリリースの可否を判断するための情報です。 そのため、不安定なテストは書かないようにすることが大前提です。 しかし、実際にはflakyであるとわかっていても修正が難しかったり、修正するための時間がないのでそのまま残すという判断をすることもあります。 Flakyなテストは削除するというのも手ではありますが不安定であってもテストが無いよりはマシとして残すこともあると思います。 github.com この提案では、Flakyなテストを扱うための機能を追加するものです。 初めの提案内容は、
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～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つの段階に分け、それぞれの効果や注意点を説明します。ソフ
テスト駆動開発者を増やした社内勉強会｜NAVITIME_Tech
🎄この記事はNAVITIME JAPAN Advent Calendar 2023の4日目の記事です こんにちは、ネコ派メタラーです。 ナビタイムジャパンでスポットデータ運用基盤の開発を担当しています。 開発業務を担当する一方で品質管理部門にも所属しており、開発プロセスの改善を通してプロダクト品質を改善する活動もしています。 開発プロセス改善の一環で、今年8月からテスト駆動開発 (Test Driven Development、以下「TDD」) を学ぶ社内勉強会を開催しています。この記事ではこの勉強会の運営、および得られた効果についてご紹介します。 きっかけ当社の品質管理部門では、自動単体テストの実装を推進し、網羅率改善などの成果を挙げてきました。一方、親和性が高いテクニックとして TDD に言及する機会もありましたが、価値を認めつつも従来の開発手法からなかなか脱却できない実態がありまし
チームで学ぶTDD輪読会 - コドモン Product Team Blog
こちらはコドモン Advent Calendar 2023の11日目の記事です🎅 qiita.com こんにちは！コドモンプロダクト開発部の村松です。 コドモンでは1週間につき半日、業務時間を自己学習に使える0.5投資制度があります。 今回は0.5投資制度を使い、チーム内で行ったTDDの輪読会について紹介します！ 輪読会スタートの背景 輪読会の進め方 輪読会のメリット チームでの変化 テストを先に書くのが当たり前に 小さくテストし、開発サイクルを回す意識 問題の言語化と改善 todoリストの活用 おわりに 輪読会スタートの背景 コドモンでは以前、t_wadaさんにレガシーコード改善ワークショップを行っていただきました。 tech.codmon.com ワークショップをきっかけにTDDへの関心がチーム内でも高まったので、今回の輪読会はTDDをテーマにスタートしました。 輪読会の進め方 輪読
リファクタリングを文化にする 〜組織が技術的負債と向き合うワークショップ〜 - MonotaRO Tech Blog
皆さんこんにちは。 CTO-Office の香川とEC開発-Bグループの竹原です。 11/28に 和田卓人氏(id:t-wada)を講師としてお招きしてテストとリファクタリングのためのワークショップを開催いたしました。 技術者正社員のうちプログラミングをすることの多いメンバー全体の約1/3にあたる総勢53名が参加しての開催となりました。 本記事ではまず第一弾としてワークショップの概要や目的、全体の流れについて簡単にご紹介いたします。 また第二弾(2024年1月公開予定)では、運営とワークショップの問題の作問に関わったメンバーにそこでの学びや実践について紹介いただきます。 開催に至った経緯とMonotaRO DOJO MonotaRO DOJO とは 社内の課題とワークショップの目的 開催経緯 ワークショップの全体像と開催までの段取り ワークショップの全体像 概要 タイムテーブル 開催までの
テスト駆動開発のはじめの一歩｜t_wadaさんに聞く1人で始める自動テストのコツと考え方 - Agile Journey
アジャイル型の開発が導入されていない現場であっても、そして一人であっても、実践可能なアジャイルに関するプラクティスは存在します。 例えば、自動テストや、テストファースト、テスト駆動開発（TDD：Test Driven Development）です。ユニットテストフレームワークを使ってテストコードを書いて開発しながらテストを実行する「自動テスト」、実装の前にそのテストコードを書く「テストファースト」、テストと実装を繰り返しながらインクリメンタルに設計・開発を行うのが「TDD」。これらプラクティスのなかで、はじめの一歩となるのが自動テストですが、1人で実践するには、どこからはじめるか、どうテストを組み立てればよいのか、あるいは自分のテスト方法は適切なのか、不安を持つこともあるでしょう。 そこで本稿では、さまざまなチームや組織へのテスト手法の導入を支援し、精力的に講演や執筆などを行ってきたこの分
research!rsc: Go Testing By Example
I opened GopherCon Australia in early November with the talk “Go Testing By Example”. Being the first talk, there were some A/V issues, so I re-recorded it at home and have posted it here: Here are the 20 tips from the talk: Make it easy to add new test cases. Use test coverage to find untested code. Coverage is no substitute for thought. Write exhaustive tests. Separate test cases from test logic
t_wadaさんと「単体テストの使い方/考え方」の疑問点についてディスカッションしました - DeNA Testing Blog
こんにちは、SWETグループの田熊です。 現在SWETグループでは書籍「単体テストの使い方/考え方」の輪読会を実施しています。 輪読会ではメンバー同士で活発に意見が交わされていますが、著者の主張に疑問を感じる箇所もあり、一度グループ外の方とも意見を交換したいと考えていました。 そこで、t_wadaさんをお招きし「単体テストの使い方/考え方」についてディスカッションする機会を設けました。 本記事では、SWETメンバーとt_wadaさんとのやりとりを紹介したいと思います。 ディスカッションの流れ ディスカッションは事前にSWETグループのメンバーが書籍を読んで疑問に感じたテーマを挙げてもらい、t_wadaさんの意見を聞くという流れで行いました。 今回は次のテーマについて話をしました。 「退行に対する保護」があるテストとはなにか 「リファクタリングへの耐性」のトレードオフはあるのか 統合テストの
チーム開発を加速するテストの育て方
テストを書いてないというチームには色々理由があると思いますが、「何をテストすべきかわからない」「書き方がわからない」「どのくらいメリットがあるかわからない」という意見は多いのではないでしょうか？テスティングフレームワークの選定や使い方を学ぶのは重要ですが、それ以上にテストの目的や戦略を学ぶことが重要です。チーム開発においてテストを活かすのは相応の知識とスキルが必要になりますが、活かせればテストは開発スピードを維持・促進する飛び道具になり得ます。 本稿は筆者が取り組んで実際に高いチーム満足度と速度を得られた、テスト戦略についてまとめたものです。
テスト駆動開発(TDD)ハンズオンのすすめ - RAKUS Developers Blog | ラクス エンジニアブログ
こんにちは、あるいはこんばんは。すぱ..すぱらしいサーバサイドのエンジニアの(@taclose)です☆ 弊社では先日テスト駆動開発（以降、TDDと呼ぶ)ハンズオン勉強会を開催しました！ 今回の記事の内容はズバリ２つ 誤解してる!?テスト駆動開発の良さ！学ぶ事の意味！ TDDハンズオン勉強会を開催する意図や実施内容、感想！ 読者のターゲットは TDDを誤解している人 TDDハンズオン勉強会を弊社でもやろう！とか思ってる人 を想定していますっ。 誤解されがちなTDD、記事にするには書ききれないTDD...なるべく小難しい内容は省いて興味を持ってもらうための記事を書いてみようと思います！ テスト駆動開発（TDD）は良い物だ！ テスト駆動開発（TDD）とは何か？ TDDに対する誤解 TDDハンズオンについて TDDハンズオンの趣旨 TDDハンズオンの計画 事前準備 スケジュールと概要 TDDハンズ
テストケースの名前には条件と結果を含めた方が良い - 感情を込める
という考えにたどり着いたので、考えのスナップショットをとっておく。 Go言語における、テスト関数名とサブテストのname引数の値を「テストケースの名前」・「テスト名」と呼ぶことにしている。 (*testing.T).Run(name string, f func(t *testing.T)) bool テスト名に近いものとして、(*testing.T).Errorや(*testing.T).Logの引数がある。これらはテスト実行時の出力に含まれるが、テストケースを分かつものではない。あくまで、特定のテストケース内の情報を増やすものだ。対するテスト名は、（通常は）テストケースを分割できる最小単位である。 テストケースがテスト名の単位で存在するということは、テスト名はそのテストケースを十分に表現できていたほうがよいということだ。さもなくば、検証・変更しようとする仕様に対応するテストケースや、実
「龍が如く7 光と闇の行方」の自動テスト活用事例とテスト自動化チーム（仮）による若手育成の取り組みについて
GAME CREATORS CONFERENCE '20の講演資料です。 動画のURL：https://youtu.be/jTIIeKKM68Q 『「龍が如く7 光と闇の行方」の自動テスト活用事例とテスト自動化チーム（仮）による若手育成の取り組みについて』 株式会社セガ 第1事業部 阪上直樹
t_wadaさんの「レガシーコード改善ワークショップ」体験記🦁 - コドモン Product Team Blog
こんにちは！コドモン開発部の加藤です。 すっかり暑くなってきましたね。我が家では猫が換毛期を迎えて、家中毛だらけになりながらも日々なんとか暑さを乗り切っています。 最近コドモンでt_wadaさんにレガシーコード改善ワークショップを行っていただきました。 今回はそのワークショップの様子についてレポートしていきます！ レガシーコード改善ワークショップの概要 t_wadaさんの紹介 ワークショップの目的と内容 目的 1.午前の部 2.午後の部 ワークショップ中のハイライト 午前の部 活発な実況チャンネル🗣️ テストを書いただけでは設計はよくならない、を実感する😬 質問コーナーではE2E肥大化の課題に注目が集まる👀 午後の部 最初のテスト作成をライブコーディングで学ぶ💪 実践を始めると意外と手が動かない……🥺 人が1on1を受けている姿をみられるの貴重👏 まとめ レガシーコード改善ワー
hypothesis+panderaで始める、データフレームに対するProperty Based Testing - Sansan Tech Blog
技術本部 R&D研究員の前嶋です。梅雨の季節ですが、少しでも快適に過ごせるようにOnのCloud 5 wpを購入しました。水に強くて軽快な履き心地で最高ですね。(追記：この記事の公開作業をしている間に梅雨が終わってしまいました) 今回は、データフレームのテストについての記事です。 データフレームのテストをどう書くか データが中心となるサービスのネックになるのが テストをどう書くか です。というのも、データフレームは行×列の構造になっているため、入力あるいは出力値がデータフレームになるような関数が多いプログラムでは、テストケースを書くのが非常に面倒です。仕様の変更があった場合、それぞれのテスト用の疑似データに修正を加えることを考えると、より簡潔にデータフレームのバリデーションをする方法が欲しいところです。実は、データフレームのテストはProperty Based Testingという考え方と
ユニットテストのガイドラインを作成しました | メルカリエンジニアリング
この記事は Merpay Tech Openness Month 2022 の15日目の記事です。 はじめに こんにちは。Credit Design Teamでバックエンドエンジニアをしている@tanaka0325です。主にメルペイスマート払いの開発をしています。 この記事では、先日私のチームで作成したユニットテストのガイドラインについて紹介します。 課題 現在私が担当している「メルペイスマート払い」のマイクロサービスは、もともと「メルカリ月イチ払い」として提供されていたコードを流用し、新規要件となる機能を追加して作られたマイクロサービスです。 マイクロサービス化するにあたり、「メルカリ月イチ払い」にあったデータはマイクロサービスリリース後に随時マイグレーションをする方針になったので、既存のデータをマイグレーションしつつ、定額払いなどの新規機能を追加してきました。メルペイスマート払いのマイ
テストコードの設計について考える
はじめに 現代の開発では、自動テストコードは必須です。しかし、そのテストコードの設計については伝えづらいと感じています。この記事では、自分が何に着目してテストコードを書くか、どのようなテストコードを書いて、どのようなテストコードを書かないかについて記載します。 前提条件、あるいは書かないこと この記事では自分の経験に基づいており、次の点に依存した記事になっています。 コードレビューが行えるチーム開発 Python + Djangoによる開発 静的型付け言語など、当てはまらないこともあると思います。 機能テストのみ 逆に言えばE2Eテストや非機能テストなどは除きます。 この記事では次のことについては基本的に書きません。 テストコードの実際の書き方 「テストを通すこと」を目的としない 当たり前すぎて言うまでもありませんが、「テストを通すこと」を目的としてはいけません。テストが通らないならテスト
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
実録レガシーコード改善 / Working with Legacy Code: the True Record
サバンナ便り〜自動テストに関する連載で得られた知見のまとめ（2023年5月版）〜 / Automated Test Knowledge from Savanna 202305 edition
質とスピード（AWS Dev Day 2023 Tokyo 特別編、質疑応答用資料付き） / Quality and Speed AWS Dev Day 2023 Tokyo Edition
