テストコードの品質を客観的な数値で担保しよう〜Mutation Testのすすめ〜YAPC::Hakodate 2024 での登壇資料です。 https://fortee.jp/yapc-hakodate-2024/proposal/a91375cf-5d1c-4abf-bedf-b291c685e056
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～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つの段階に分け、それぞれの効果や注意点を説明します。ソフ
eBPFを使った自動テストツール「Keploy」がすごい
この記事はKeployのバージョンv2.0.0-alpha53 を前提に執筆しております。 Keployとは KeployはeBPFを利用して取得できるWebアプリケーションの通信に関するトレース情報を元に、テストとそのテストの実行時に利用するスタブサーバーを生成することができるツールとなります。 公式サイトのトップには以下のようなスローガンが掲げられています。 2 minutes to 90% test coverage! テストに苦労した経験のある方は興味を惹かれるのではないでしょうか。 現在まだアルファ段階のプロジェクトですが、GitHubスター数は2683（2024/01/04現在）、CNCF Landscape にも掲載されているなど、一定の注目を集め始めているOSSです。 開発主体はプロダクトと同名のKeployというインド発のスタートアップで、去年GoogleによるインドのA
test_profを用いたRailsの自動テストの高速化の実践例 - SmartHR Tech Blog
このエントリは、SmartHR Advent Calendar 2023 シリーズ1の5日目の記事です。 こんにちは！SmartHRでプロダクトエンジニアをしている大澤(@qwyngg)です。 最近Railsの自動テストの高速化について調べていたので、その内容をまとめてみました。 主にtest_profというgemを用いた解析と、その結果を元にした改善方法について書いています。 test_profとは https://github.com/test-prof/test-prof テストのパフォーマンスを分析する様々なツールを提供するgemです。 色々機能があるのですが、今回は以下の機能を使って発見した問題とその解決方法を紹介します。 factory_botプロファイラ テストに対してstackprofを(面倒な設定無しで）実行できる 詳しい使い方はTestProf: Ruby tests
「龍が如く7 光と闇の行方」の自動テスト活用事例とテスト自動化チーム（仮）による若手育成の取り組みについて
GAME CREATORS CONFERENCE '20の講演資料です。 動画のURL：https://youtu.be/jTIIeKKM68Q 『「龍が如く7 光と闇の行方」の自動テスト活用事例とテスト自動化チーム（仮）による若手育成の取り組みについて』 株式会社セガ 第1事業部 阪上直樹
第7回 テストコードの認知負荷 ～テストの名前、構造、情報量を工夫する～ | gihyo.jp
サバンナ便り ～ソフトウェア開発の荒野を生き抜く～ 第7回テストコードの認知負荷 ～テストの名前、構造、情報量を工夫する～ 開発の現場では、既存のテストコードから仕様を読み解く機会がよく訪れます。そのようなとき、テスト対象の仕様やテストの意図を読み解きやすいテストとそうではないテストがあることに気付きます。今回はテストコードの読み解きやすさに寄与する要素を考えます。 認知資源と認知負荷 人間は何かを読み解くときに脳のリソース（脳内のワーキングメモリ）を使います。リソースの量は有限で、個人差があります。このような脳のリソースは「認知資源」と呼ばれています。 人間が何かを読み解くときに認知資源が何にどのくらい割かれているかという概念を「認知負荷」と言います。「どのくらい」は状況に左右されます。たとえば、読み解く対象を知っているかどうかで認知資源が割かれる量は変化します。「何に」も状
超便利！PostmanのAPIパフォーマンステストで簡単かつ素早く性能フィードバックを手に入れよう - Qiita
はじめに 先日（2023年6月15日）、PostmanのAPIパフォーマンステストが正式にリリースされました。この機能により、Postmanのコレクションに登録されているAPI群に対して、手軽にクライアントから負荷をかけ、APIのパフォーマンスや性能問題などの確認ができるようになりました。PostmanでAPI開発しながら素早くサクッとAPIの性能フィードバックが得られることがこの機能の魅力です。 本記事ではその使い方、注意点・制限などについて簡単にご紹介します。 Postman APIパフォーマンステストを使ってみる 事前準備 APIパフォーマンステストは、2023年6月時点でPostmanデスクトップアプリからのみ利用可能です。まだインストールしていない方はこちらよりダウンロードしてください。 次に、機能紹介で利用するサンプルAPIを用意します。ここではPublished Postma
10Xのテストコード規約 - 10X Product Blog
はじめに こんにちは！モジュール開発部のyamakazu (@yamarkz) です。 10Xではテストコードの標準化を目指して、テストコード規約 (Test Coding Standards) を整備してきました。この記事では数ある規約の中でも、実際に活用して効果が大きかったものをいくつか取り上げて紹介します。 テストコードの品質に課題を持っている方や、コーディング規約の整備に関心を寄せる方の参考になれれば幸いです。 ChatGPT 要約 ChatGPTに内容の要約をお願いしました。この記事で述べられている内容は以下の通りです。 テストコードに規約を設ける目的は、「テストの資産性を高めることで、プロダクトの発展性と事業の継続可能性を守るため」である。テストコード規約は、ボトムアップで開発組織全体が守る基準を明確にし、良質なテストを書くために設ける。この規約ではGroup, Arrange
APIシナリオテストの新ツールrunn
runn is 何？ ３行まとめ 今回はAPIシナリオテストツールのrunnをプロジェクトに導入し、一部機能のコントリビュートしながら3ヶ月間触ってみておすすめだと感じたことを記事にまとめたいと思います。 runnとの出会い 4ヶ月ほど前にスキーマ駆動開発を行っているプロジェクトでいい感じのAPIのテストをしようと色々 調査 をしていました。 その当時はOpenAPIでスキーマ定義してswagger-uiからポチポチ手動テストをしていましたが、APIの数も増えるし同じAPIでもパターンが結構あり、流石に手動でのテストでは限界があるなーと考えていました。 パラメータ数も多いのでControllerテストで書くにしてもコード量が多く、レビューが辛いと感じていました。 APIをE2Eでテストしたい、最終的にはCIで自動テストまでもっていきたいと思いました。 しかし、いざ調べてみると案外ニーズにマ
過度なDRYは読みやすさの敵！？「リーダブルテストコード」という発表をしました #vstat - give IT a try
先日、このブログでもお伝えしましたが、「VeriServe Test Automation Talk No.3」というオンラインイベントで登壇してきました。 veriserve-event.connpass.com 申込者数はなんと1000人を超えていて、大変驚きました。 僕は「リーダブルテストコード」というテーマで発表しました。スライドはこちらです。 Twitterでたくさんシェアされたり、はてなブックマークがたくさん付いたり、こちらもすごい反響でビックリしました。 で、どんな内容だったの？ ひとことで言うなら「テストコードを徹底的にDRYにしようとしちゃダメよ！」というお話です。 このネタは昔からQiitaやTwitterとかでことあるごとに話してきましたが、この勉強会であらためてなぜダメなのか、DRYに書かず、どう書くべきなのか、という話を力説してみました。 優秀なプログラマほど、「
なぜ我々はユニットテストが書けないのか？｜SHIFT Group 技術ブログ
はじめにこんにちは！Unit～E2Eのテスト自動化を生業にしている、いしいと申します。 ユニットテストに限らず、何かを始めようと思ったとき、人は様々な壁に直面しますよね。知識・経験の問題、コストの問題（金銭、時間）、メンタルの問題（納得感、不安感）、それらが複合的に結びつく社内政治的な問題などなど・・・。そして、それらの壁を乗り越えて第一歩を踏み出すことには大変な困難を伴います。 この記事では、ユニットテストを書いていくのにあたって、どのような壁・問題があるのかを確認し、それに対してどのようにアプローチをすれば乗り越えられるのかを考えていこうと思います。 ユニットテストの壁とその乗り越え方メンタルの問題根本的にモチベーションが上がらない それはユニットテストのメリットや魅力に理解、納得がいっていないからです。人間、無駄なことをやりたいとはなかなか思えません。仮に、無駄と思いながらやったとし
リーダブルテストコード / #vstat
「リーダブルなテストコードについて考えよう ～VeriServe Test Automation Talk No.3～」で使用したスライドです。 https://veriserve-event.connpass.com/event/243280/ 登壇動画はこちらで公開されています。 http…
世界中のITエンジニアが悩まされている原因不明でテストが失敗する「フレイキーテスト」問題。対策の最新動向をJenkins作者の川口氏が解説（前編）。DevOps Days Tokyo 2022
世界中のITエンジニアが悩まされている原因不明でテストが失敗する「フレイキーテスト」問題。対策の最新動向をJenkins作者の川口氏が解説（前編）。DevOps Days Tokyo 2022 世界中のITエンジニアが悩まされている問題の1つに、テストが原因不明で失敗する、いわゆる「フレイキーテスト」があります。 フレイキーテストは、リトライすると成功することもあるし、失敗する原因を調べようとしてもなかなか分かりません。GoogleやFacebookやGitHub、Spotifyといった先進的な企業でさえもフレイキーテストには悩まされています。 このフレイキーテストにどう立ち向かうべきなのか、Jenkinsの作者として知られる川口耕介氏がその最新動向を伝えるセッション「Flaky test対策の最新動向」を、4月21日、22日の2日間行われたイベント「DevOps Days Tokyo 2
手動テストだけのソフトウェアは腐っていく: 柴田 芳樹 (Yoshiki Shibata)
この本で、著者のRobert Martinも、次のように述べています。 この10年間の間に この業界では多くのことがありました。1997年当時、テスト駆動開発などという言葉は誰も聞いたことがありませんでした。ほとんどの人にとって、単体テストというのは動作をひとたび『確認』したら捨ててしまうものでした。苦労してクラス メソッドを書き上げ、それらをテストするためのその場しのぎのコードをでっちあげていたのです。 『Effective Java』で有名なJoshua Blochは、この本の中のインタビューで、次のような会話を行っています。 「デバッグの話をしましょう。あなたが追いかけた最悪のバグはどのようなものでしたか」 それに対して、Joshua Blochは、 「最初に勤めた会社で私が開発したソフトウェアですね。ソフトウェアのデバッグに1週間半費やしました」 という話をしています。 1週間半費
質とスピード（2022春版、質疑応答用資料付き） / Quality and Speed 2022 Spring Edition
質とスピード（2022春版、質疑応答用資料付き）
テスト技法を使って論理的な根拠を作る｜Shogo Nameki
アルプのQAエンジニアをしている nametake です。 最近QAチームが発足し、プロダクトチームと協調してテストプロセスを改善しています。 QAチームはまだ発足したばかりで、QA専任は私1人です。それに対しプロダクトチームは3つあり、私自身がアルプ全体のQAプロセス改善や採用にフォーカスしているのもあり、各プロダクトチームに入っての活動は出来ていません。 その代わりQAコーチとして「開発チーム内のQA関係のことは積極的に壁打ち相手になります」という方針を社内に共有し、プロダクトチーム内のQA関係の課題の解決指針を一緒に決める、という活動をしてきました。 来た相談を打ち返し続けていたところ、プロダクトチームからやってくる相談の傾向として「どこまでやれば大丈夫なのかという不安」が根っこにに多くあることに気づきました。 対象機能ごとに、どこまでテストをするべきかというのは異なるため、1つの解
自動テスト速度改善 - 自動テストが品質のボトルネックとならないために - freee Developers Hub
freee人事労務の品質改善を専任で活動している keik です。 freee人事労務ではアプリケーション開発の自動テスト環境として CircleCI を利用しています。すべてのコードの変更は GitHub 上の Pull Request を経由して行われますが、Pull Request のマージ条件の一つとして自動テストをパスすることを求めるようにしています。 つまり、どんな些細な変更であっても、急ぎの変更であっても、リリースするためには基本的には自動テストの結果を待つ必要があります。一方で、コードベースは日々成長しており、それに比例して自動テストの実行時間も長くなっています。 ここに、ゆっくりと、ジレンマが生じはじめます。 品質を高める目的の自動テストだが、実行時間が長いと品質のボトルネックになりうる。 具体的には以下のようなシナリオが考えられます。 些細な改善が億劫になる（自動テスト
Autifyを導入して1年3ヶ月経ったので振り返ってみる - ANDPAD Tech Blog
はじめに こんにちは。QAエンジニアの佐藤です。 以前ブログを書いたのが1年以上前ですね... 時間が経つのは本当に早いです。 tech.andpad.co.jp あれからSlackのアイコンは複数回変わり、今は "ミミッキュ" ではありません。 ということで、 Autifyを1年3ヶ月使い続けてきた振り返りをしてみたいと思います。 autify.com 目標に対しての達成率 以前のブログで 現状は、当初目標としていた主要動線テストの1/3を自動化できましたが、今年中には1/2以上は自動化していきたいと思っています。 と目標を立てていました。 実際どうだったでしょうか？(`･ω･´) ・ ・ ・ 達成しました＼(^o^)／ 888 今年の4月に行われたイベントで 88% を自動化できている、と報告がありまして、 Autifyで自動化できるケースは自動化しきりました。 目標達成していますね！
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - tadashi0713/howtheytest-jp: 日本のソフトウェア企業のテスト・テスト自動化に関する資料をまとめています
A/Bテスト概論 / Introduction of ABTesting
