テストコードを書き始める前に考えるべきテストの話（2023年版） #cedec2023
以下のイベントの投影資料です。 https://cedec.cesa.or.jp/2023 お問い合わせは https://twitter.com/nihonbuson まで。 【発表資料中のURL】 P14 ゼロから始める「テスト設計」の書（ゲームテストの世界） - JaSST’17 Kyushu https://www.jasst.jp/symposium/jasst17kyushu/pdf/S4.pdf P18 ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2011.J02 https://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2011.J02.pdf P19 ソフトウェア開発201の鉄則 https://bookplus.nikkei.com/atcl/catalog/96/1
テストコードにはテストの意図を込めよう #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
続・ノハナのテスト自動化
ノハナの中の様子を時に真面目に時にゆるゆるとお伝えします こんにちは、QAエンジニアの武田です。 去年の健康診断で、メタボ予備軍と言われ、キックボクシングを始めたのですが、思うように成果に繋がっていません。。。 もうすぐ今年の健康診断が迫っているので、何かいい減量方法があったら教えて下さい🙇 さて、今日は、前回、テスト自動化の取り組み初期についてご紹介してから約2年が経過した今、どのように運用しているか、その成果など、テスト自動化の現状をお話したいと思います。 Before まず、前回紹介した際の構成がこちらです。 テストは、 Jenkins から 定時点 でリクエストされ、 ローカルPCにつないだ実機 で実行していたのですが、本格的に運用していくには解消すべき大きな課題が2点ほどありました。 1点目は、 環境のメンテナンスが必要 ということです。 テスト実行のリクエストとテスト結果をS
何度も挫折してきたE2Eテストだけど、今後はDatadog Synthetics Testsが良さそうかも - LIVESENSE ENGINEER BLOG
これは Livesense Advent Calendar 2022 DAY 20 の記事です。 はじめに 株式会社リブセンスの転職会議事業部Webエンジニアの @ishitan-liv です。 今回は、過去に転職会議でも導入しようとして挫折してきたE2Eテストについて書きます。 E2Eテストを自作するか、SaaSを使うのかで比較した結果と、Datadog Synthetics Testsの使い方を軽く紹介したいと思います。 なお、この導入については完全に個人プロジェクトとしてやっております。 リブセンスではエンジニアの権利として毎月10%の技術投資枠確保というものがあり、Googleの20%ルールのようなもので、約20日勤務だと想定して2日間は興味のある技術的なことに使えます。 grow.google はじめに このブログ記事を読むと得られる(と思われる)もの 今回書かないこと 導入検討
mablでE2Eテストを自動化するためのベストプラクティス 2020年版
毎日200シナリオ以上、月に1万シナリオ以上、月に1万ステップ以上を実行して安定化ができてきた経験をどこでも実現できるように、これまでの知見・経験をまとめてみようとおもいます。mablのようなサービスを使って、安定したE2Eを作るときの参考になれば。 QA自動化サービスとは何か？ ここではmablをベースにまとめますが、ノーコードでありキャプチャ＆リプレイ形式でテスト実行できるツールであれば、似たような作りになっているはずなので参考になるかなーと思います。mablの基本的な使い方については以下を参考にどうぞ。 https://daipresents.wordpress.com/2019/mabl/ 掟1. 観点はひとつ ひとつのテストの中に、観点（確認したいこと）が複数あった場合、1つ目の観点でテストが失敗した場合に、2つ目の観点はテストされません。よって、観点はひとつにするべきです。 観
mablを一年運用してみた成果と課題 - エムスリーテックブログ
こんにちは！ エムスリーエンジニアリンググループ QAチームの城本（@yuki_shiro_823）です。担当しているBIR（Business intelligence and Research）チームでローコード自動化サービスmablを運用した所感を紹介します。 前提 今期行ったこと メリット リグレッションテストが必要なときにすぐ対応できる QA環境を正しい状態に保ちやすい デメリット（というか自動化により発生するコスト） 継続的なメンテナンスコストが発生する 不安定なテストを作ると本来かけたくないコストが生じる コラム：mablの実行環境の違い 今後の課題 まとめ We're hiring! 前提 エムスリーではテスト自動化にローコード自動化サービスmablを利用しています。 mablとはブラウザの操作を記録することにより、ローコードでテストケースの作成を行えるテスト自動化サービスで
localStorageを使ったVueプロジェクトのユニットテストがnot definedでコケる件 | DevelopersIO
localStorageを使ったVueプログラムを書いて、それのユニットテストを書いたところコケてしまいました。調べてみるとVueに限らず、フロントのユニットテストではあるあるなようですので、忘れないためにもエントリにしておきます。 こんにちは。サービスグループの武田です。 ユニットテスト、書いてますか？ある程度大きくなってしまったプロダクトにゼロからテストを書くのはたいへんですよね。というわけで、小さいうちからテストは書くべきです。今回スモールスタートでlocalStorageを使ったプログラムを書いて、それのユニットテストを書いたところコケてしまいました。調べてみるとVueに限らず、フロントのユニットテストでは あるある なようですので、忘れないためにもエントリにしておきます。 環境 今回の検証環境は次のような環境になっています。 $ node -v v10.15.3 $ vue -V
C/C++の静的解析ツール・事例まとめ - 簡潔なQ
C/C++の静的解析は、どう考えても大変なんだけどどう考えても需要が高いので、やはり色々なソフトウェアや事例があるようだ。まとまった情報が欲しいけど見つからなかったので自分の調べた範囲でまとめることにした。 他にも耳寄りな情報があったら教えてほしい。 静的解析を行うことができるソフトウェア 調べてみると結構たくさんある。それぞれの特徴とかあまりよくわからない。 (個人的には、とりわけ網羅的な形式的検証ができるツールの性能に興味があるので、それを中心に集めていたが、やはり網羅的とは限らないで探すともっとたくさん見つかるようだ。もちろん網羅性にはトレードオフがある) Frama-C …… C言語に形式手法を適用するための汎用のフレームワークで、静的検証のためのプラグインも多数(WPとかValueとか)存在する。網羅的な検証から発見的な手法、動的な手法まで様々ある。研究で使うのに便利そう Ast
xUnit Test PatternsのTest Doubleパターン(Mock、Stub、Fake、Dummy等の定義) - 千里霧中
最近、昔作ったTest Doubleの解説資料を参照・引用してくれる方がちらほら出ていて恐縮しているのですが、見直してみると結構わかりにくい資料なので今回文章としてまとめたいと思います。内容は世間一般的に言われているMock、Stub、Fake、Dummyといった言葉の定義になります。 Test Doubleとは Test Doubleとは、テスト実行時に、テスト対象が依存しているコンポーネントと置き換わるものです。「テスト代役」と訳されることもあります。世の中でMock、Stub、Fake、Dummyなどと呼ばれているものの総称に位置づけられます。 簡単な例を以下に示します。このコードでは、テストメソッド「テストコード()」がメソッド「テスト対象()」をテストしています。また「テスト対象()」は、中でメソッド「外部メソッド()」を実行しています。なお「外部メソッド」はテスト対象でないとし
現場で役立つテストの基本 - Qiita
ウォーターフォールモデルの場合、テストフェーズと、テスト設計のインプットとなるドキュメントあるいはテスト観点がV字型に対応するVモデルという手法が広く知られています。 しかし、「テストタイプ○○は××フェーズでやるべき」「テストタイプ○○には××技法を使わなければならない」という決まりがあるわけではありません。 開発プロセスが何であれ、要は、テスト対象ソフトウェアに求められる品質特性を充足できるよう、テスト全体を戦略的に計画すれば良いのではないでしょうか。 2. テストマネジメント 2.1. テスト計画 前述した組織のテストプロセスに基づいて作成 テストフェーズと、実施するテストタイプを定義 品質管理の計画値を策定 コード網羅率（カバレッジ） KStepあたりのテスト項目数 KStepあたりの不具合摘出数 など テスト体制 スケジュール テストの完了条件 2.1.1. コード網羅率（カバレ
「カバレッジが高ければ、品質が高い」と誤解している危険な思想家の皆様へ - Qiita
皆さんは 「カバレッジが高ければ、ソースコードの品質が高い」という誤解 をしていませんか？少なくとも私は今までテストカバレッジ100%を追求していました。「C0/C1カバレッジ100%」がユニットテストの完了条件として含まれているプロジェクトも多いかと思います。 本稿では、「カバレッジが高ければ、ソースコードの品質が高い」という命題がなぜ誤っているのかを論理的に証明し、カバレッジを計測する本当の目的、そして推奨されるカバレッジの目標値について紹介したいと思います。 「カバレッジが高ければ、ソースコードの品質が高い」はなぜ間違っているのか？ カバレッジを計測する本当の目的 バグを潜在させてしまう恐怖のテストケース・アンチパターン カバレッジの目標値は100%にするべきではない カバレッジの目標値は何%にするべきなのか？ （テストカバレッジの種類については『ホワイトボックステストにおけるカバレ
[読書メモ]実践Junitのメモ2 - Qiita
第Ⅱ部 合言葉で覚えるユニットテスト テストの生産性を上げるためのガイドラインの章 5章 First(良いテストとは) よいテストはFIRSTである Fast(迅速) Isorated(隔離) Repeatable(繰り返し可能) Self-validating(自律的検証) Timely(タイムリー) Fast(迅速) 高速に実行できること。(1日に2〜3回実行するのが苦痛であれば、見直そう) 遅いコードへの依存を減らす DB等低速なリソースにアクセスをしなくてもいいよう設計する Isolate(テストを隔離する) それぞれのテストが独立して振る舞い、規則正しく機能すること テストが失敗する理由が複数ある場合、分割することを検討する 時期や順序に依存しない 単一責任の原則 Repeatable(繰り返し可能) 実行するたびに同じ結果が得られること 繰り返しができないテストは、テスト対象の
![[読書メモ]実践Junitのメモ2 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/aed5251867a839ff726dfb0e8ec6f02548b9bfb9/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCJUU4JUFBJUFEJUU2JTlCJUI4JUUzJTgzJUExJUUzJTgzJUEyJTVEJUU1JUFFJTlGJUU4JUI3JUI1SnVuaXQlRTMlODElQUUlRTMlODMlQTElRTMlODMlQTIyJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz1lZTY0MTk2NzA3M2FjNzkzNTE0ZGY0ZjNmZDk3MWM2Nw%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDB0b3NoX20mdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTc0MjVlNThkYWZlYzJmN2RmM2FiNjE3MDExNjIxYTIw%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D5eae69b7583c068ba60a3d6daee1a00d)
kintoneチームを支えるSeleniumテスト
The document introduces ros_whill, an open source ROS package for the WHILL personal electric vehicle. It provides joystick control, sensor data like joint states, battery status, IMU readings and odometry. The package works with ROS2 and there are plans to improve ROS2 support. WHILL is hiring for roles involving ros_whill and ROS2 integration.
リーダブルテストコード - Qiita
はじめに よく言われるように、ソースコードというものは書かれることよりも読まれることの方が多く、それゆえ読みやすいコードを書くということが非常に重要です。それはテストコードにおいても同様であり、プロダクトコードと同等に資産として扱う必要があります。 テストコードは具体的な値を用いて記述し、また複数の変数の値の組み合わせでテストケースを起こすため、プロダクトコードと比べて冗長になりがちです。 書籍『リーダブルコード』の14章でもテストコードの読みやすさについて触れられていますが、本稿では読みづらいテストコードをリファクタリングして読みやすくするためのテクニックを紹介したいと思います。 なおサンプルコードはJavaScriptで記述されており、そのテストコードはJest1を用いて書いています。 ソースコードはGitHubにあります。 リファクタリング(その壱) 以下の、決して読みやすいとはいえ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Why Good Developers Write Bad Unit Tests
GitHub - goldbergyoni/javascript-testing-best-practices: 📗🌐 🚢 Comprehensive and exhaustive JavaScript & Node.js testing best practices (July 2023)
アジャイルチームのためのインテリジェントなテスト自動化ソリューション | mabl
ソフトウェアテスト読書マップ
GitHub - localstack/localstack: 💻 A fully functional local AWS cloud stack. Develop and test your cloud & Serverless apps offline
.pdf)
Software Development island :: Sergey Drozdov