GitHub - web-platform-tests/wpt: Test suites for Web platform specs — including WHATWG, W3C, and others
The web-platform-tests Project is a cross-browser test suite for the Web-platform stack. Writing tests in a way that allows them to be run in all browsers gives browser projects confidence that they are shipping software that is compatible with other implementations, and that later implementations will be compatible with their implementations. This in turn gives Web authors/developers confidence t
WPTをChromeで実行してHTML5 APIを理解する - Qiita
WPTとは WPT (web-platform-tests)という、ブラウザを作っている人のためのテストスイートがある。これは、ブラウザがどう動くべきかを定義している様々なWeb標準を、各ブラウザが満たしていてるかを確認するためのテストなのだが、Webサイトを作っているWebデベロッパーが新しいWebのAPIをどう使ったらいいかを調べるときにも役立つと思う。 という話を、電車で横に座っていたとある人に話したら「じゃあ、やり方を(日本語で)紹介してくださいよ。」と言われたので、簡単に紹介したい。 手軽に試す 手軽に試したければ、https://w3c-test.org 以下にある目的のテストファイルを開くといい。 例えば、Service Worker Navigation Preloadのテストであれば https://w3c-test.org/service-workers/service
BackstopJSの落ちたテストをリトライしてレポートを1つにまとめてくれるコマンドラインツールを作った - hitode909の日記
社のプロダクトではビジュアルリグレッションテストのためのツールであるBackstopJSをここ半年くらい使っている。referenceという正解データの画像と、testとして開いてキャプチャした画像を見比べて、差分があれば失敗、というテストを書ける。テストケースの設定がJSONを書くだけなのでテストを書くコストが低いのと、結果的に画像に出る形でテストすることを強制される、というシンプルさが気に入っている。過去にはE2Eテストをいろいろ試したけどどれも最終的に滅びてしまい、BackstopJSはそんななか生き残っている希望のテクノロジー。 リリース前の確認フローにも使っているし、書いてる途中のコードの動作確認にも使えて、数ピクセルの意図しないズレを検知できたりしている。 便利だけど、運用上苦労している点もあって、テストの書き方が悪かったり、ネットワークの調子が悪かったり、で確率的に落ちるテス
同期エンジンの心臓部を書き換える
0 0 719 0 この 4 年間、Dropbox では、デスクトップ クライアントの同期エンジンを白紙の状態から再構築しようと懸命に取り組んできました。同期エンジンは、デスクトップ パソコン上の Dropbox フォルダの陰に隠れた魔法です。これは、Dropbox で最も長く使われているコード部分であり、最も重要なコード部分の 1 つでもあります。今回、新しい同期エンジン（コードネーム「Nucleus」）をすべての Dropbox ユーザー向けにリリースさせていただくことを、ここに発表いたします。 同期エンジンの書き換えは本当に大変な作業で、多くの環境でマイナスともなりうる構想であったことに鑑みると、手放しで祝う気持ちにはなれません。結果的には Dropbox にとって素晴らしいアイデアであったわけですが、それは、私たちがこのプロセスにどのように取り組むべきかを熟考したからこそ、たどり着
Launchable に join した！！ - 宇宙行きたい
初出社（リモートだけど）なうhttps://t.co/G7Vnv5sg1n— 生存バイアスの王 (@yoshiori) May 17, 2020 求む、同志 - 川口耕介のブログ を読んで「めっちゃ面白そう！！ とりあえず話したい！！」と衝動に突き動かされるまま行動してたら join していました。 前職でも 「なんかテクノロジーカンパニー世界トップ 10 みたいなの、よく記事になってるじゃん。Google, Amazon, Apple とか Netflix とかが入ってるやつ。あれにアジアで一番最初に入り込むような企業になりたい」 とか言ってたんだけど（多分 Alibaba が今は一番近い気がする）同じような情熱と危機感を持っている川口さんと話してめちゃめちゃ興奮しました。 まぁ、でも英語全然だめなのでいつかなにかしらの形で一緒にできたらなくらいの気持ちで「やっぱり英語もう一回ちゃんとや
RSpecによるユニットテストの書き方 – recompile.net
最近、新人のテストコードを見る機会があり、ユニットテストの書き方について考える機会があった。ユニットテストはテンプレートみたいなものがあるので、それさえ押さえれば、誰でも簡単に書くことができる。 ここでは、その方法について紹介したい。サンプルはRSpecで書くが、その他のユニットテストフレームワークでも、応用ができるとおもう。 はじめに ごく単純化すると、テスト対象は状態を持ち、入力を与えると何らかの出力を行なうものである。入力が変われば出力は変化するし、状態が変化すると入力が同じでも出力が変わる（かもしれない）。 ユニットテストは、テスト対象の状態を操作し、与えた入力によって意図通りの出力を得られるかを確認する作業のことをいう。なので、ユニットテストを書くときには、オブジェクトの状態ごとにメソッド単位で入力と出力を確認するようにする。 RSpecの疑似コードで書くと、次のようなテンプレー
おまえは今まで実行したassertの回数を覚えているのか？あるいは新しいアサーションユーティリティのご提案 - teppeis blog
JavaScript Advent Calendar 2014 11日目。 いきなり要約: Promiseや非同期テストのアサーションを簡単確実に書けるようになるesplanというライブラリのPoCを作った話。 Promiseや非同期のテストは難しい 詳しくはJavaScript Promiseの本: Chapter.3 Promiseのテストをご覧いただきたいのだが、Promiseのテストを正確に書くのはそんなに簡単ではない。 例えばmochaだと、 // 間違ったテスト1: // mayBeResolveWithOne() が1以外でresolveしたときタイムアウトエラーになる it("mayBeResolveWithOne()は1でresolveする", function(done) { mayBeResolveWithOne().then(function(value) { as
ava-to-jest.md
ava-to-jest.md AVAからJestへの移行 大枠の書き方 テストケースの定義 AVAのtest('コメント', () => {/* テスト内容 */});という書き方（xUnit形式）はJestでも可能です。AVAではimport test from 'ava';という感じでtest関数をインポートしていましたが、Jestではグローバル変数として定義されているのでインポートは不要です。test関数だけでなく、Jestが提供するAPIは全てグローバル変数で定義されているので、importせずに参照できます。 // AVA import test from 'ava'; test('テストケース名など', t => { t.true(true); }); // Jest // 全てのAPIはグローバルに定義されており、importは不要 test('テストケース名など', ()
GitHub Actions の matrix と cache 使ってe2eワークフローを作る - Qiita
動いてるリポジトリはここ https://github.com/mizchi/frontend-gh-action-playground やったこと 発想は https://qiita.com/mizchi/items/9c03df347748ba5f5a11 の続き job 間の依存を明示して build => {各種e2e} というステップでタスクを流す 新たに導入された actions/cache を使って node_modules と dist (webpack 出力ディレクトリ) を cache して次のジョブに渡す node_modules は package.json の ハッシュ値をキーに、 dist は GITHUB_SHA(コミットハッシュ)をキーにした safaridriver が仕様変更で動かなくなったので一旦止めた(サポートにこれ先月動いてたのに今動かないの？って
フロントエンドでTDDを実践する（react-testing-libraryを使った実践編） - Qiita
この記事は、フロントエンドでTDDを実践する（理論編）の続編として書きました。 本記事では、react-testing-libraryでReactでTDDする方法をサンプルを使って解説します。 react-testing-libraryは、PayPalのエンジニアでありフロントエンドのTDDの第一人者であるKent C Doddsが、enzymeのリプレイスを意図して作ったReactのための新しいテストユーティリティです。 設計思想は、The more your tests resemble the way your software is used, the more confidence they can give you. enzymeのように実装そのもののテストをするよりも、ユーザーが使うようにテストされるべきというフィロソフィーがAPIに強く反映されています。 実際には、いくつか
市場バグを引き起こした優秀なデータたち - ボドゲを愛するテスト屋さん
※この記事は「ソフトウェアテストの小ネタ Advent Calendar 2017 - Qiita」用の記事です。 ソフトウェアテストの小ネタ 2日目担当のオムそばです。 実はちゃんとした(?)記事を書くのはこれが初めてなので、生暖かい目で見ていただければ。 そんなわけで早速表題の件、市場バグを引き起こした優秀なデータたちをご紹介します。 今回は、よくある「半角記号」、「空白やスペース」などは割愛させていただきます。 (2017/12/26追記)"市場バグ"という言葉に違和感や疑問を持たれた方は、こちらの記事をどうぞ。文言について整理してみました。 ■日時に関するデータ ・1969/12/31、2038/1/20：UNIX系のシステムに有効なデータ。UNIXのシステム時刻は1970/1/1 開始なので、それ以前のデータを打ち込むと予期せぬエラーが発生する可能性がある。また、同様に2038/
テストがなかった無法地帯にテストを導入して開発速度を1.7倍にした話 - Qiita
テストがなかった無法地帯のプロジェクトに自動テストを導入して、開発速度を1.7倍にした話をします。 自動テストがなぜないのか 自動テストのないプロジェクトには、そうなる理由が必ず存在します。よくみる理由は、「時間がないから1」「テストの書き方がわからないから」「無理やりテストを書いたつらい経験があったから2」といったものです。今回のプロジェクトの場合は、以下の2点でした： 自動テストの書き方がわからないから レビューがテスト代わりだったから まず、チーム編成が変わって私ともう一人がチームに加わるまで、実装者の中に自動テストの経験者はいませんでした。このような状況では、自動テストは困難になります。なぜなら、何をどうやってどこまでテストするかを決めるには、多少の慣れが必要だからです。この慣れがないと、何をしたらいいかわからないという状態に陥りがちで、結果として自動テストが後回しにされてしまいま
シンボリック実行に入門しようとした | 一生あとで読んでろ
はじめにシンボリック実行(symbolic execution)という用語をセキュリティ系の論文でよく見かけるようになった．ここでは，シンボリック実行の基礎となる理論を辿る．筆者はソフトウェアテストの研究には疎く，おそらく本稿には若干以上の誤謬と誤解が含まれているだろう．ぜひ識者の教示を乞いたい． 発祥シンボリック実行は主にソフトウェアテストの領域で古くから研究されてきたトピックである．シンボリック実行という用語の初出は遡ること38年前，James C. KingらによるSymbolic Execution and Program Testing [PDF]という論文だ．Dijkstraがgoto文の濫用による大域脱出を批判したのが1968年であり，Guarded Command Languageを提案したのが1975年のことである．この論文が発表された1976年当時はまさに構造化プログラ
2017年JavaScriptのテスト概論 | POSTD
本稿は、JavaScriptのテストについて最も重要な根拠、用語、ツール、アプローチなどの知識を身に着けることを目的とした簡略版ガイドブックです。本稿で検討する数々の側面に関する最新の秀逸な記事も紹介しつつ、私たちが経験的に得たことも多少付け加えたいと思います。 Facebookによるテスト用フレームワークであるJestのロゴをご覧ください。 見てお分かりのように、このフレームワークは「苦痛のない」JavaScriptのテストをスローガンに掲げています。しかし、 “次のように言う人” もいます。 苦痛のないテストなんてあり得ない。 実際、Facebookはこのスローガンを掲げるだけの素晴らしい理由があります。一般的にJSのデベロッパは Webサイトのテストにあまり満足していません 。JSのテストには制限があり、実装が難しく、低速である傾向があります。 一方、正しい戦略を立てて適切にツールを
Bashアプリケーションをテストする | POSTD
以前、bashスクリプトをテストする仕事に取り組んだことがあります。最初、Pythonユニットテストを使うことにしましたが、プロジェクトに外部技術を持ち込むのは気が進みませんでした。そこで、仕方なく、悪名高い bash で書かれたテスト用フレームワークを使いました。 既存ソリューションの概要 手に入るソリューションを探してGoogle検索しましたが、選択肢はほんの少ししかありませんでした。そのうちいくつかについて、詳しく見ていきましょう。 重要になるのは、どんな基準でしょうか？ 依存関係： bass のテスト用フレームワークを選ぶときに、 python 、 lua などのシステムパッケージも一緒に引きずり込むのは嫌ですね。 インストールの難しさ：継続的な開発の実装とTravis CIでの継続的な統合も仕事の1つだったので、私にとってインストールにかかる時間と手間数が妥当だということは、重要
テスト書きすぎ問題 - hitode909の日記
テスト書きすぎるとよくないって言ってる人がいた．DHHっていう人．作業時間の1/3以上テストしてたらおかしいとか，ActiveRecordのバリデーションなど，Railsの機能はテストしない，とか． Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので... - Sooey 偉い人が言ってるからという理由で，テスト手抜き派の人に良い材料を与えてしまった．僕は意見ちがって，作業時間半分以上はテスト書いたりしてる． テストたくさん書くと，最初に書くときのコストは増える．けど，あとから読む時や，変更したい時には，読むだけだし，書くのも差分だけで良い．コード本体を理解できれば，要らないテスト捨てるのは，落ちたのを消すだけだから簡単．あとで見て，テスト足りないと分かったときに，明文化されてない仕様からテストを補う
power-assert + babel as a development tool
3行まとめ espower-babelは役目を終えたので、Deprecated Babel + power-assertはbabel-preset-power-assertを使う コード上はrequire("power-assert")とrequire("assert") どちらでもpower-assert化できるようになった espower-babelは非推奨へ Babel + Mocha + power-assertの組み合わせを出来るだけ設定ファイルなどを作らずに使えるespower-babelというモジュールを書いていましたが、役目を終えたので非推奨(deprecated)にしました。 テストコードをES6+power-assertで書けるespower-babel 3.0.0リリース | Web Scratch 理由としては、Babel@6からは設定(ファイル)を必ず必要とするの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
クロスブラウザテストの闇と闇と闇
Vueコンポーネントのユニットテスト
From Library to Tool - power-assert as a General Purpose Assertion Enhancement Tool
