You 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
tl;dr ファイルをそれ単独で単体テストとして実行するボイラープレートを編み出した そのヘルパとして mizchi/test という実装を作った なぜソースコードにテストを書きたいか Rust や Python の doctest ではソースコードにテストを書く方法があります。 ソースコードにテストを書けると、コードとテストの心理的な距離が近くなってテストが書きやすくなる、という肌感があります。(諸説あります) 実装とテストが混ざって汚れるのが嫌という意見も理解できますが、それはありつつ認めた上で、あとでリファクタする前提で最初の一歩をその実装に書けると嬉しい、という気持ちがあります。 現状の Node だととりあえず assert するだけという単純なテストを書くことは可能ですが、構造化する方法がないので、簡単なスクラッチの時ぐらいしか行われません。 // test.js import
2021/09/13 Open8 で発表したフロントエンドテストプラクティスの話です。
はじめに time.Now関数を用いたコードをテストする場合、テスト対象のコードに次のような変更を加える必要があります。 引数に現在時刻を渡す パッケージ変数やフィールドなどに現在時刻を返す関数やインタフェースを設定する context.WithValue関数でコンテキストに現在時刻を設ける どの方法を用いてもプロジェクトの初期から考慮する必要があります。途中で変更するとなると修正が箇所を漏れなく探し出す必要があります。また、パッケージ変数に現在時刻を返す関数を設定した場合、テストを並列に実行することを諦める必要が出てくるでしょう。 このような課題を解決するために、testtimeというライブラリを作成しました。 テストの並列実行と時刻の固定 次のようにパッケージ変数を使ってtime.Now関数のラッパーの挙動を変えてテストする手法があります。 var nowFunc func() tim
#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
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
ユーザーが使うように操作をすれば一連の内容がそのままテストシナリオに。非エンジニアや入社まもないメンバーもすぐにテストを作り始めることができるのでテスト自動化をスケールさせられます 詳細ページへ
こんにちは。メルカリのテストエンジニアとして、スマホアプリのテスト自動化をぶりぶりしている@daipresentsです。 テスト自動化をすすめるにあたり、効率のよいテストを作るために、既存のテストケースについて調べる機会がありました。その過程で現状のQAプロセスも確認したのですが、以下のようなテストケース管理の課題があることがわかりました。 それぞれのテストエンジニアが、それぞれの方法で、それぞれのテストケースを管理しているため、ナレッジが横につながりにくい。 共有されているリグレッションテスト項目の更新が追いついておらず、情報が古くて使いにくい。 人数が増えてきて、ふりかえりや改善がやりにくい。 1については、現在、職能横断的なチーム構成になっているため、プロジェクトやプロダクトに集中できる環境である反面、それぞれのチームにいるQAエンジニアどうしのつながりが薄れてしまうことが原因に感じ
以前開発のドキュメントをどこに置くか問題 - $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_
Facebookテストユーザー作成ツールを公開します。 Create and Delete tool for Facebook Test Users 1.テストユーザーの概要 「Facebookテストユーザー」とは何か?というところから説明します。 Facebookではアプリケーション動作確認のために、テストユーザー作成機能が提供されています。Facebookのデフォルト機能を確認することもできるようです。 スクリーンショットは作成したテストユーザーでログインしたところです。 テストユーザーはFacebookアプリにひもづいて作成します。主に以下の機能があります。 ひもづいてるアプリケーションにアクセスできます テストユーザー同士で友人になることができます テストユーザーは複数作成できます(1アプリケーションにつき500まで) 複数作成できるので、異なるブラウザで別々のテストユーザーでログ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く