GitHub - utkusen/reqstress: a benchmarking&stressing tool that can send raw HTTP requestsYou signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Node/Deno でソースコードにテストを書く
tl;dr ファイルをそれ単独で単体テストとして実行するボイラープレートを編み出した そのヘルパとして mizchi/test という実装を作った なぜソースコードにテストを書きたいか Rust や Python の doctest ではソースコードにテストを書く方法があります。 ソースコードにテストを書けると、コードとテストの心理的な距離が近くなってテストが書きやすくなる、という肌感があります。(諸説あります) 実装とテストが混ざって汚れるのが嫌という意見も理解できますが、それはありつつ認めた上で、あとでリファクタする前提で最初の一歩をその実装に書けると嬉しい、という気持ちがあります。 現状の Node だととりあえず assert するだけという単純なテストを書くことは可能ですが、構造化する方法がないので、簡単なスクラッチの時ぐらいしか行われません。 // test.js import
フロントエンドテストプラクティス in open 8
2021/09/13 Open8 で発表したフロントエンドテストプラクティスの話です。
スレッドセーフなテスト用の時間を固定するライブラリを作った - tenntenn.dev
はじめに time.Now関数を用いたコードをテストする場合、テスト対象のコードに次のような変更を加える必要があります。 引数に現在時刻を渡す パッケージ変数やフィールドなどに現在時刻を返す関数やインタフェースを設定する context.WithValue関数でコンテキストに現在時刻を設ける どの方法を用いてもプロジェクトの初期から考慮する必要があります。途中で変更するとなると修正が箇所を漏れなく探し出す必要があります。また、パッケージ変数に現在時刻を返す関数を設定した場合、テストを並列に実行することを諦める必要が出てくるでしょう。 このような課題を解決するために、testtimeというライブラリを作成しました。 テストの並列実行と時刻の固定 次のようにパッケージ変数を使ってtime.Now関数のラッパーの挙動を変えてテストする手法があります。 var nowFunc func() tim
ts-jestとESM - lacolaco notes
#Jest v27 / ts-jest v27 https://jestjs.io/ja/docs/next/ecmascript-modules Node.js の --experimental-vm-modules オプションが必要 ESMとして扱いたいファイルの拡張子を extensionsToTreatAsEsm で宣言する必要あり JestがESMをサポートしている状態では内部的に supportsStaticESM フラグがtrueになる このフラグを明示的に外から指定はできない。総合的判断される ts-jestに渡したtsconfigのmodule設定はリスペクトされていない https://github.com/kulshekhar/ts-jest/blob/a4b88ca076e1e2a367e01341b8bd0e21033ec422/src/compiler/ts-c
アンチフラジャイルの世界
ソフトウェア設計における 意思決定とそのレビューの秘訣Yoshitaka Kawashima4.7K views•39 slides
hygen で生成 - 対話形式の Component 雛形 -
Component 作成にあたり、storybook や test も一度にコミットする場面が増えてきました。そして CSS Modules や、特定 Component 専用の custom hooks など、一つの Component を構成するファイル群はそれなりの量になってきます。例えば、以下の様な module 構成の Component です。これを手作業で作成するとなると、少し億劫になりますよね。 └── atoms └── Button ├── Button.stories.tsx ├── Button.test.tsx ├── Button.tsx ├── dependencies.ts ├── index.tsx └── style.module.css 作成時にButtonという名称だけ決めてしまい、CLI から雛形出力できれば、作業効率向上が見込めます。（story
Autify(オーティファイ), AIを用いたソフトウェアテスト自動化プラットフォーム - Autify(オーティファイ)
ユーザーが使うように操作をすれば一連の内容がそのままテストシナリオに。非エンジニアや入社まもないメンバーもすぐにテストを作り始めることができるのでテスト自動化をスケールさせられます 詳細ページへ
モダンなテスト管理プロセスのためにテスト管理ツール３つを比較検討したはなし | メルカリエンジニアリング
こんにちは。メルカリのテストエンジニアとして、スマホアプリのテスト自動化をぶりぶりしている@daipresentsです。 テスト自動化をすすめるにあたり、効率のよいテストを作るために、既存のテストケースについて調べる機会がありました。その過程で現状のQAプロセスも確認したのですが、以下のようなテストケース管理の課題があることがわかりました。 それぞれのテストエンジニアが、それぞれの方法で、それぞれのテストケースを管理しているため、ナレッジが横につながりにくい。 共有されているリグレッションテスト項目の更新が追いついておらず、情報が古くて使いにくい。 人数が増えてきて、ふりかえりや改善がやりにくい。 １については、現在、職能横断的なチーム構成になっているため、プロジェクトやプロダクトに集中できる環境である反面、それぞれのチームにいるQAエンジニアどうしのつながりが薄れてしまうことが原因に感じ
設定の仕様をドキュメントに書くのではなく、テストにしてしまう - $shibayu36->blog;
以前開発のドキュメントをどこに置くか問題 - $shibayu36->blog;という記事を書いた。まだよい方法はちゃんと考えられてないが、少しずつケースバイケースでいろいろな手法を試してみている。今回は設定項目の仕様のドキュメントという観点で考えたときに、テストを作ることで解決できないか、ということについて書く。 設定項目の仕様 例えば以下の様な設定があったとする*1。 [ { "blog_url" : "http://shibayu36.hatenablog.com/", "permission" : "public", "can_be_edited_by" : [ "shiba_yu36" ] }, { "blog_url" : "http://shibayu36-private.hatenablog.com/", "permission" : "private", "can_be_
テストを書く文化を育てる戦略と戦術
at DevLOVE現場甲子園2013 2013/11/09 (土) http://http://devlove.doorkeeper.jp/events/5464Read less
Facebookテストユーザー作成ツール
Facebookテストユーザー作成ツールを公開します。 Create and Delete tool for Facebook Test Users １．テストユーザーの概要 「Facebookテストユーザー」とは何か？というところから説明します。 Facebookではアプリケーション動作確認のために、テストユーザー作成機能が提供されています。Facebookのデフォルト機能を確認することもできるようです。 スクリーンショットは作成したテストユーザーでログインしたところです。 テストユーザーはFacebookアプリにひもづいて作成します。主に以下の機能があります。 ひもづいてるアプリケーションにアクセスできます テストユーザー同士で友人になることができます テストユーザーは複数作成できます（1アプリケーションにつき500まで） 複数作成できるので、異なるブラウザで別々のテストユーザーでログ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TDD実践を経て変わったこと
Dockerと継続的インテグレーション