ちょっとしたウェブアクセスクライアントのコードを書いていて、サーバー側に正しくリクエストが送られているかの確認をする場合、モックサーバーを建てることが多いと思います。ウェブフロントエンド開発とかだとMock Service Workerが便利ですし、Playwrightのネットワークフック機能も便利です。GETだけならPythonでいつもやってしまうのですが、今回はPowerShellで作ったちょっとした自動化ツールかつエラーレスポンスを返したい、という状況だったので、Goあたりで適当なサーバーでも書くかな、と思っていたところ、ふと思い立ってぐぐってみたところでMockoonという良さげなツールを見つけて、使ってみたら便利だったので紹介します。 Mockoonとは僕は知らなかったのですが、2017年ごろからあるモックを作成するツールのようです。 GUIが提供されており、APIの定義やログ閲

はじめに現代のWebアプリケーションにおいて、ユーザが写真や動画などのファイルをアップロードする機能は、しばしば求められます。 本記事では、ファイルアップロードを実現するための一手段として、「署名付きURL」を利用した方式を取り上げ、その設計について詳しく解説します。 今回は、Amazon Web Services（AWS）を利用する前提のもと、このアプローチを探求していきます。 前半部分は署名付きURLをそもそもよく知らない方向けの導入部となっていますので、要点だけ抑えたい方は設計上のポイントから読まれることをお勧めします。 ファイルアップロードの実現方式パターン署名付きURLの話をする前に、ファイルアップロード機能をWeb APIとして実現する方式について、いくつか代表的なものを紹介します。 Pattern 1. multipart/form-datamultipart/form-da

Swaggerを使う事になり OpenAPIを触ってみると 3.0.3 と 3.1.0 が存在します。どちらを使うべきが悩んだので調べて整理してみました。 3.0.3 から 3.1.0 への変更点は過去のポストを参照ください。 参考: Open API Specification 3.1と気になる仕様策定 結論Amazon API Gateway を使い、OpenAPIで定義されたAPI仕様書のインポート機能 を利用する場合は 3.0系（ 3.0.3）一択です。理由は単純に執筆時点では Amazon API Gateway が 3.1系 に対応してないからです。 また、VSCodeの拡張機能の中には 3.0.3 に対応しているものの 3.1.0 には未対応のものも多いようです（決して 3.1.0 で書けないわけではないありません） https://github.com/42Crunch/v

タイトルで言いたいことは言ってしまっているのですが、2017年ぐらいからNext.jsを使ってきて、最新の情報のキャッチアップとかもそんなに苦労はなくて、こだわりがないならNext.jsでいいのでは？ という記事です。 Next.jsは大きすぎる？フレームワークが大きいのはたいていそうで、提供されているすべての機能を使うわけではなく、その一部だけを使います。そのサブセット自体がシンプルであればフレームワークはどれだけ大きくても問題はないはずです。JavaとかPythonとかGoのコード書いてもごく一部のライブラリしか使わないわけで、でもそれに対して「ライブラリがでかすぎる」とは言わないですよね。 Next.jsは「より高速にする」機能がたくさんありますが、別にそんなの最初から使う必要はないですし、サービスによってはそもそもその機能が合わない、というのもあります。ユーザープロフィール画面にI

Playwright連載5日目です。 近年PlaywrightやCypressを用いたE2Eテスト（エンドツーエンドテスト）が行われるようになってきました。 E2Eテストとはソフトウェアやシステムの全体的な動作や機能をテストする手法で、ユーザーが実際に行う操作を模倣したテストを行い、アプリケーションが予想通りに機能するかどうかを確認していきます。 具体的な操作手順をテストケースとして作成し、予期される結果との整合性を確認していくわけです。バグの早期発見のためにも、E2Eテストの自動化を行い、さらにはCIに組み込み定期的に実行していきたい。そしていざ組み込んでみると、CIの実行時間が気になってきます。 テスト自体の実行時間も短縮を行っていきたいですが、テストが始まるまでのイニシャライズ、初期処理の時間もそこそこ掛かってしまうもの。 今回はどのように設定していけば処理時間が短くなるか。試行錯誤

はじめに皆さんこんにちは。踊るエンジニア木戸です。 Playwright連載3日目の今回は、その便利機能たちをCypressと比較しながら紹介します。Cypressで馴染みの便利機能がPlaywrightではどう実現されているのか、E2Eテストに関わる関係者の悩みを解決するどんな便利機能が備わっているのか、詳しく見てみましょう。 テストコード生成の補助まずはテストコードを記述する際の便利機能について紹介します。 Playwrightでは、テストケースに沿ったアクションを実行させるために、まず操作対象のDOMを取得する必要があります。Test generator機能を使用すると、実際に対象ページをブラウザで表示させ、操作対象にマウスオーバーすることで、DOMを取得するためのコードを生成してくれます。

Playwrightあるいはそのロケーターの元ネタとなっているTesting Libraryでは、DOMを指定する方法として data-testid 属性を扱ったクエリーを提供しています。どちらでも getByTestId(ID文字列) メソッドを使い、この属性値を使った要素の取得が行えます。しかし、ドキュメントを見ると、PlaywrightもTesting Libraryも、「他の手法が使えないときの最終手段」としています。 In the spirit of the guiding principles, it is recommended to use this only after the other queries don’t work for your use case. Using data-testid attributes do not resemble how your