テストコードを書き始める前に考えるべきテストの話（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
Testing in Production, the safe way
Author’s Note: I’m greatly indebted to Marc McBride for reading a draft of this post and offering some excellent suggestions. This is the second installment in my series on testing distributed systems. The posts in this series are the following: Testing Microservices, the sane way (published December 2017) Testing in Production, the safe way (published March 2018) Testing in Production: the hard p
Introduction | Pact Docs
Pact is a code-first tool for testing HTTP and message integrations using contract tests. Contract tests assert that inter-application messages conform to a shared understanding that is documented in a contract. Without contract testing, the only way to ensure that applications will work correctly together is by using expensive and brittle integration tests. Do you set your house on fire to test y
A compilation of outstanding testing articles (with JavaScript) | Practica.js
A compilation of outstanding testing articles (with JavaScript)Testing the dark scenarios of your Node.js applicationPractica v0.0.6 is aliveIs Prisma better than your 'traditional' ORM?Which Monorepo is right for a Node.js BACKEND now?
何度も挫折してきた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とはブラウザの操作を記録することにより、ローコードでテストケースの作成を行えるテスト自動化サービスで
グーグルのファズテストツール「OSS-Fuzz」、数カ月で1000件以上のバグ発見
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます Googleのバグ検出ロボット「OSS-Fuzz」によって、この数カ月で1000件以上のバグが見つかった。 Chrome SecurityのエンジニアであるOliver Chang氏とAbhishek Arya氏、ソフトウェアエンジニアのKostya Serebryany氏、Google SecurityのプログラムマネージャーであるJosh Armour氏によると、OSS-Fuzzボットはこの5カ月間、ウェブを徹底的に調査し、悪用される恐れのあるセキュリティ脆弱性を検出してきたという。 OSS-Fuzzボットはファジングとして知られる手法を用いて、バグを発見する。ファジングとは、システムやソフトウェアにランダムなデータを大量に入力して
localStorageを使ったVueプロジェクトのユニットテストがnot definedでコケる件 | DevelopersIO
localStorageを使ったVueプログラムを書いて、それのユニットテストを書いたところコケてしまいました。調べてみるとVueに限らず、フロントのユニットテストではあるあるなようですので、忘れないためにもエントリにしておきます。 こんにちは。サービスグループの武田です。 ユニットテスト、書いてますか？ある程度大きくなってしまったプロダクトにゼロからテストを書くのはたいへんですよね。というわけで、小さいうちからテストは書くべきです。今回スモールスタートでlocalStorageを使ったプログラムを書いて、それのユニットテストを書いたところコケてしまいました。調べてみるとVueに限らず、フロントのユニットテストでは あるある なようですので、忘れないためにもエントリにしておきます。 環境 今回の検証環境は次のような環境になっています。 $ node -v v10.15.3 $ vue -V
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - opendiffy/diffy
250bpm
Why Good Developers Write Bad Unit Tests
GitHub - goldbergyoni/javascript-testing-best-practices: 📗🌐 🚢 Comprehensive and exhaustive JavaScript & Node.js testing best practices (July 2023)
dubzzz/fast-check: Property based testing framework for JavaScript (like QuickCheck) written in TypeScript
GitHub - rsmbl/Resemble.js: Image analysis and comparison
アジャイルチームのためのインテリジェントなテスト自動化ソリューション | mabl
ソフトウェアテスト読書マップ
GitHub - ngneat/falso: All the Fake Data for All Your Real Needs 🙂
GitHub - mailhog/MailHog: Web and API based SMTP testing
