GoでSQLの複雑なクエリのテストを書いてみた - ZOZO TECH BLOG
はじめに こんにちは。ブランドソリューション開発本部FAANSバックエンドブロックの佐野です。普段はサーバーサイドエンジニアとして、FAANSのバックエンドシステムを開発しています。 FAANSとは、弊社が2022年8月に正式ローンチした、アパレル店舗で働くショップスタッフの販売サポートツールです。例えば、コーディネート投稿機能や成果確認機能などを備えています。投稿されたコーディネートはZOZOTOWNやWEAR、Yahoo!ショッピング、ブランド様のECサイトへの連携が可能です。成果確認機能では、投稿されたコーディネート経由のEC売上やコーディネート閲覧数などの成果を可視化しています。 本記事では、成果データの集計処理におけるBigQueryのクエリ実行処理のユニットテストをGoで実装した取り組みと、その際の工夫についてご紹介します。 目次 はじめに 目次 成果データの集計処理とは 抱え
【Jest】モック関数入門
はじめに Jestではじめるテスト入門や フロントエンド開発のためのテスト入門が届き、 テスト欲が高まっている土屋です。 Jestでの単体テストを行う際に、 「似たようなメソッドがあるけど、何が違うんだ？」という疑問が生まれたため、 前述の2つの本を参考にJestでのモックの方法を整理していきたいと思います。 モックとは xUnit Patterns Test Doubleより引用 モックとは、テスト対象の一部もしくは全てを代替オブジェクトで代用する手法であり、 広義の意味では「テストダブル」と呼ばれています。 xUnit Patterns によると、テストダブルには ダミー: コンパイルを通すために必要なコンポーネント スタブ: 代替オブジェクトで設定した値を返す スパイ: パラメータ、呼び出された回数、戻り値などを記録 (狭義の意味での)モック: 代替オブジェクトで期待する内容の検証
フロントエンドのテスト構成について考えてみた in 2023
はじめに この記事では、 フロントエンドの開発において意義のあるテストはなにか？ それらをコスパよく実現するためにはどうすればよいか？ について考えて、作った構成を紹介します。 前提 下記の技術スタックを利用していますが、これ以外のスタックでも応用可能な仕組みが多いと思います。 Next.js Storybook playwright msw msw-snapshot （拙作） 注意事項 この記事の構成は、まだまだ実験的な機能だったり怪しい技術が一部採用されています。 msw-snapshot 拙作のライブラリであって、動作が怪しい可能性がめっちゃあります。 Next.js の testmode playwright + msw を実現するために必要でした。 まだまだ全然まともに動かないかもしれません。（サンプルリポジトリの単純なテストは動いた） サンプル 下記のリポジトリにサンプルを用意
Next.jsでServer Componentsがちょっとだけテストできるようになってた
先日 Vercel の@leeerob氏が次のようなツイートをしていました。 I'm working on updated testing docs for the @nextjs App Router. next@canary supports Jest for server & client components, metadata, server-only, and more なんと next@canary で、Server Components の Jest でのテスト実行がサポートされているとのことです！これは試さないと！ next@13.4.19 時点での Server Components テストの課題 Next.js App Router で開発するときの大きな課題の一つがテストで、現状では Server Components と testing-library を組み合わ
Jestのuiテストがつらすぎるので愚痴らせてください。そしてブラウザテストで本質的なuiテストをしよう
ここから下で話す際、主に使う言語・フレームワーク・ツールとしては - Typescript - React (Next.js) - Jest - React Testing Library - ブラウザテストツールとしてPlaywright を前提としています。ただ話す内容の本質的な部分はVueでもSvelteでも、Vitestだろうがあまり変わらないだろうなと思ってます。そう思って見ていただけると助かります。 現代ではReactでUIの単体テスト・インテグレーションテストを書く場合、Jest x React Testing Library を使うのが一般的かと思います。皆さんはJestでUIテストを書いていますか？Jestでコンポーネントの単体テストを書いていると辛いことがたくさんありませんか？例えば 大量のライブラリのモックによる(これってテストやる意味あるの・・・？)と感じる虚無感
UIテストはもうMaestroでいいのかもしれない話
App Router への移行は「改善」となり得るのか？/ Can migration to App Router be an improvement
フロントエンド開発の単体テストにおけるモックのベストプラクティス
はじめに 単体テストの考え方/使い方にモックのベストプラクティスが記載してあったので、フロントエンド開発の単体テストに取り入れた場合の有効性を共有したいと思います。 ※本稿ではReactを取り上げていますが、その他ライブラリ・フレームワークでも活用できる内容です！ 良い単体テストを構成する4本の柱 前提に良い単体テストを構成するものとして、下記の4本の柱を紹介します。 ⭐️：モックのベストプラクティスに関連する柱 退行に対する保護⭐️ ソフトウェアで発生する退行とはバグのことであり、何らかの変更（新規機能追加・削除等）を加えた後に既存の機能が意図した挙動でなくなることを指す。その大綱から保護される仕組みを作り出すことを重視した観点。 リファクタリングへの耐性⭐️ テストが失敗することなく、どのくらいのプロダクションコードへのリファクタリングが行えるか。プロダクションコードを変更する度にテス
Webフロントエンドのための実践「テスト」手法 CodeZine Night #1
CodeZine編集部主催のウェビナー「CodeZine Night」の第一回発表資料 https://codezine.connpass.com/event/279012
mswjs/data で広がるテスト戦略
本稿は MSW（Mock Service Worker）エコシステムのうちの一つ mswjs/data を試してみた記事です。記事中のサンプルコードは以下で公開しています。 mswjs/data とは 仮想 DB をブラウザ（インメモリ）に展開する、データモデリング・リレーションライブラリです。MSW 単体ではハードコードされたフィクスチャのみの定義となりますが、mswjs/data を併用することで、データ駆動型 API モックを作成することが可能になります。使い始めは簡単で、以下の様にスキーマを定義しfactory関数で DB インスタンスを生成します。 import { factory, primaryKey } from '@mswjs/data' const db = factory({ user: { id: primaryKey(String), firstName: Str
Webフロントエンドにおける網羅的テストパターンガイド
こんにちは、テストが好きなsilverbirderと申します。Webフロントエンドのテストは実施していますか？ユニットテストやビジュアルリグレッションテストは広く知られていると思います。しかし、パフォーマンステストのためのテストコードはありますか？また、カオスエンジニアリングテストやアクセシビリティテストはありますか？ 今回、私はWebフロントエンドにおける網羅的なテストパターンを調査し、その結果をここで紹介したいと思います。これらを理解することで、読者の皆さんが適切なテスト戦略を策定する際の参考になれば幸いです。 前提 今回、テスト対象として取り上げる題材は、TodoMVCというTODOアプリです。フレームワークとしてReactを使用しますが、紹介するテストパターンはフレームワークに依存しないものです。ただし、使用するライブラリはReactに関連しているため、その点についてはご了承くださ
フロントエンドテスト、モジュールモックでStorybookのインタラクションテストの開発コストを下げる
Storybook のインタラクションテストのコストを下げる Storybook を使用すると、ブラウザ上で動作を確認しながらテストコードを記述できるため、生の Jest よりも開発が容易になります。ただし、Storybook には Jest にある重要な機能である jest.mock がないという欠点があります。jest.mock は、テスト対象のコンポーネントがインポートしているモジュールをフックして、簡単にモックを作成することができますが、Storybook ではこの機能は使用できません。ビルド時に他のファイルへの干渉が防止されてしまいます。 この問題を解決するために、以下の Addon を使用することで、jest.mock と同じような機能を Storybook 上で利用することができます。 npm サンプルプログラム 動作内容 ログイン用フォームの動作チェック FormMock.
Web フロントエンドにおける API モック戦略
はじめに 新規開発のプロジェクトでテスト戦略を立ててしばらく開発をしています。そのテスト戦略の内の 1 つに Web API モックの運用ポリシーを決めていたのですが、大きな問題がなく運用ができているので「API モック戦略」と大袈裟に題してみました。 特に奇抜なことはしていないですが、振り返りとしてまとめたいと思います。 目的 Web フロントエンドの開発時にモック API を利用して動作確認・自動テストをしたい 開発サーバを起動するだけでブラウザで動作確認をしたい Testing Library などを用いた UI コンポーネントの振る舞いを自動テストしたい モックデータの管理を簡単にしたい ブラウザでの動作確認と自動テストで同じモックデータを利用したい 前提 API のモックサーバは Mock Service Worker （以下 MSW と呼ぶ）を利用する。MSW のメリットや利用
testing-library でユーザの気持ちになって書くフロントエンドのテスト
TL;DR フロントエンドのテストが壊れやすく要因の一つは、ユーザがどのようにソフトウェアを使うかをクエリに反映できていないからかも testing-library はソフトウェアを使うユーザの気持ちを反映させやすいようにクエリの優先度をつけていて、それに従うほうがいい 優先度の低いクエリも役に立つことがある 運用しているアクセシビリティなどの実装のガイドラインに沿うようなテストを作るとき アクセシビリティの低い実装をリファクタリングするためのテストを作るとき はじめに フロントエンドのテストに用いるツールとして testing-library が知られています。testing-library は提供しているクエリに優先度をつけています。この優先度は、どういう基準でつけられているのでしょうか。 この記事では、 testing-library のガイドを読みながら、クエリの優先度を「ユーザの
フロントエンドにおけるテスト駆動開発の実践と概説
はじめに 自動テストが叫ばれて10数年以上の時を経ていますが、今なお開発者の興味を惹くトピックの1つであります。 実際、Developers Summit 2023ではテストを主題とした講演が多く、また人気も博したと耳にします。 さて自動テストと共に話題になるトピックの1つと言えばテスト駆動開発でしょう。 ただテスト駆動開発は、設計・開発手法のため自動テストとは厳密にはジャンル違いであり、誤解を受けがちなトピックでもあります。 またテスト駆動開発を解説する書籍の多くが、Java等のオブジェクト指向言語のスタイルで書かれているためフロントエンドエンジニアのコードスタイルとは若干差異があリます。 当記事ではフロントエンドエンジニアのためにテスト駆動開発の技法の数々をTypeScript、Reactを用いて実践します。 フレームワークとしてReactを採用しましたが、記事内のコードはモダンフロン
JestとVitestのisolateについて
現状 Vitest が Jest など他のテスティングフレームワークに比べて遅くなる場合があることがわかっています。 (確実に遅くなるとはいえない。が、私自身もテストの速度が遅くなったことを経験しています。) また Vitest を実行する場合、--single-threadオプションをつけると速くなるということもわかっています。 (0.29.0以前は --no-threads) 公式 Docs にも最大３倍速くなることが記載されています。 WARNING This option is different from Jest's --runInBand. Vitest uses workers not only for running tests in parallel, but also to provide isolation. By disabling this option, yo
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[2023/10/06 - Four Keysで改善する開発生産性] フロントエンド開発における、 デプロイ頻度を上げるための テスト設計と仕組みづくりのヒント / Tips for designing and structuring tests to increase deployment frequency in front-end development![[2023/10/06 - Four Keysで改善する開発生産性] フロントエンド開発における、 デプロイ頻度を上げるための テスト設計と仕組みづくりのヒント / Tips for designing and structuring tests to increase deployment frequency in front-end development](https://cdn-ak-scissors.b.st-hatena.com/image/square/60e555b2900801a1c6cc52f41796765a4a92a91a/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F5c3a4c39012049358f4cdea43d34ba5e%2Fslide_0.jpg%3F27291210)
はんずおんVitest
webフロントエンドテストと自動化
Storybookを用いてテストの可視化を進めた話 | PR TIMES 開発者ブログ
例外を投げるな、値を返せ
