負荷テストツール４選！ユーザーが語る効果的なパフォーマンステストのプラクティス！ 登壇資料 https://trident-qa.connpass.com/event/326996/
k6を活用した再現性・拡張性の高い負荷試験基盤の構築
負荷テストツール４選！ユーザーが語る効果的なパフォーマンステストのプラクティス！ 登壇資料 https://trident-qa.connpass.com/event/326996/
grpc-goのNewClient()を使うとbufconnを使ったテストがUnavailableでコケる件の対処法
TL;DR grpc-go v1.64.0からDial()やDialContext()がDeprecatedとなった 代わりに推奨されたNewClient()を使うとbufconnを使っているテストがUnavailable(name resolver error: produced zero addresses)で落ちる 初期化として resolver.SetDefaultScheme("passthrough") を突っ込むと動くよ 原因 gRPCクライアントを作成する際、従来のDial(), DialContext()ではデフォルトのネームリゾルバーは passthrough として作成されます。 これがNewClient()からは dns になったためです。 bufconnは passthrough であることが前提で作られているためエラーになります。 rpc error: code
Goでモンキーパッチするライブラリを作った - Plan 9とGo言語のブログ
Goで単体テストを実装する場合、動的な言語のように「テスト実行中に外部への依存を置き換える」といったことはできません。代わりに、 外部への依存を引数で渡す 外部への依存をインターフェイスで渡す のように、テスト対象をテスト可能な実装に変更しておき、テストの時は外部への依存をモック等に置き換えて実行する場合が多いのではないかと思います。 個人的な体験でいえば、テスト可能な実装に置き換えていく過程で設計が洗練されていく*1ことは度々あるので、面倒を強制されているというよりは設計を整理するための道具といった捉え方をしているのですが、そうは言っても動的な言語に比べると面倒だなと感じるときは少なからずあります。既存の実装がテスト可能になっておらず、変更するコストが高い場合は特にそうですね。 そんなとき、気軽にモンキーパッチできると嬉しいんじゃないかと思って、テストの時だけ関数を置き換えられるようなラ
GoでgRPCのAPIテスト環境を構築する - enechain Tech Blog
はじめに JCEXで実践しているAPIテストについて 単体テスト 負荷テスト なぜAPIの単体テストを行っているのか API単体テストで使用するパッケージ 実例によるAPI単体テストの環境構築 前提 ステップ１: テストしたいAPIの定義 ステップ２: テストの作成 ステップ３: APIの実装 ステップ４: DBを使ったテスト ステップ５: ヘルパー関数化 ステップ６: テーブル駆動テストに変える ステップ７: フィクスチャを使ったテスト まとめ おわりに はじめに こんにちは、enechainのGXデスクでエンジニアをしている@ejiです。 GXデスクは、『日本気候取引所 - Japan Climate Exchange』 (以下 JCEX) のサービス開発を担当しており、 私は主にBFFとバックエンドのAPIをGoで開発しています。バックエンドのAPIは gRPC を使用しています。
Postmanを使い始めた時に知っておきたかった地味に便利な機能10選 - Qiita
普段何気に使っているPostman。最近まで「手軽にGUIで疎通を試せて、設定を共有できてべんり〜」くらいで使っていました。 けどふと「実はもっと便利な機能があるのでは？」と思って調べてみたところ、色々出てきたのでせっかくなのでシェアしたいと思います。 たまたまですがちょうど10選！ 地味に便利な機能10選 VSCode拡張 PostmanにはVSCode拡張機能があります。 インストールするだけで、VSCodeのサイドバーから利用可能です。 日本語設定 日本人なので日本語で使いたい。 右上の歯車→Settingsから以下の通り選択することで日本語化が可能です。 変数の定義 複数のAPIで同じ値を使いたい場合があるとします。例えばテスト用のユーザーIDなどです。 Postmanではそんな値をAPIファイルに逐一ハードコードする必要はなく、変数に保存することが可能です。 Postman Ec
Testcontainersを用いてテスト実行前の docker compose up を無くし、Goで並列テストする | フューチャー技術ブログ
Testcontainersを用いてテスト実行前の docker compose up を無くし、Goで並列テストする 春の入門祭り2024の1記事目です。 はじめにTIG真野です。 Testcontainers を用いて、単体テスト実行前に docker compose up -d 無しで、PostgreSQLにアクセスする単体テストを行う、入門記事です。 恩恵は次のような開発者体感の向上が個人的にあります。 テストを実行するうえで、別プロセスのサービスを起動しておく必要があるといった前提条件を考えなくても済むため、テストを行うビジネスロジックに集中できる docker compose up -d 打たないだけだが、テストに必要なコンテナを考慮しなくても済む 停止し忘れて、別のリポジトリの開発するときに混乱しなくても済む 並列テストしやすくなるので、テストの実行速度が向上する Goにおい
Rust製の負荷テストフレームワークGoose入門
はじめに Rustを使っているとすべてをRustで書きたい欲に駆られることがあります。 たとえば負荷試験ツールもRustで書きたい、みたいなことがあったりします。 ありがたいことにRustではGooseという負荷テストフレームワークがあり、これを使えば負荷テストをRustで実装できます。 ちなみに、GooseはRust Foundationのメンバーであるtag1が開発しているので安心感があります。[1] 本記事はGooseについて基本的・応用的な使い方などについて紹介していきます。 Gooseとは GooseはPython製の負荷テストツールであるLocustにインスパイアされたRust製の負荷テストフレームワークです。 Locustと比べて、約11倍ほどのトラフィックを生成でき、CPUコアを可能な限り使用してくれます。[2] またLocustと違い、フレームワークなのでビルドしたバイナ
CI/CDがあたりまえの今の時代にAPIテスティングツールに求められていること / CI/CD Test Night #7
https://testnight.connpass.com/event/311263/
Reduce, recycle, reuse
To enable a fast and reliable continuous integration process, McDonald’s turns to reusable workflows and GitHub Actions. By Michael Gorelik, Senior Solution Architect and Achintya Pillai, Software Engineer III McDonald’s Engineering teams are at the forefront of digital innovation, creating seamless and engaging e-commerce applications that allow customers to conveniently order their favorite meal
yamlでテストシナリオを書いてそのまま実行までできるAPIテストツールの新星 “runn” を試してみた | DevelopersIO
yamlでテストシナリオを書いたらそのまま実行できる……そんな夢のようなシナリオテストツール"runn"の紹介とやってみた記録です これまでのシナリオテストツールに対する課題感 シナリオテストツールといえば、 Cucumber や Gauge といったツールが有名です。 ですが、これらのツールは「シナリオファイル」とは別に、シナリオを実行するためのコードも書かないといけません。しかも、そのコードではAPIを呼び出す処理を特定のプログラミング言語を使って書かなければなりません。その中には、HTTP Clientを実際に操作するような処理も含まれます。 私は「シナリオテストがしたい」のであって、「シナリオに沿ってAPI呼び出しを行う処理を書きたい」のではありません。こういった課題感を、ここ数年ずっと抱えてきました。 そんなとき、ついに見つけたツールが "runn" でした。 APIのシナリオテ
Goのテスト安定性向上のためにFlakyなテストを再試行する機能を導入する提案 - tomato3713’s blog
Go言語にFlakyなテストへのサポートを追加する提案が面白かったので紹介します。 概要 Flakyなテストとは、コードに変更がないにもかかわらずテストが成功したり失敗したりと不安定な実行結果になるテストのことです。 テスト結果は本来なら全て成功ならリリース可能、1つでも失敗すればバグがあるのでリリース不可のようにリリースの可否を判断するための情報です。 そのため、不安定なテストは書かないようにすることが大前提です。 しかし、実際にはflakyであるとわかっていても修正が難しかったり、修正するための時間がないのでそのまま残すという判断をすることもあります。 Flakyなテストは削除するというのも手ではありますが不安定であってもテストが無いよりはマシとして残すこともあると思います。 github.com この提案では、Flakyなテストを扱うための機能を追加するものです。 初めの提案内容は、
負荷テストツール「k6」入門
こんにちは。 PharmaX でエンジニアをしている諸岡（@hakoten）です。 この記事の概要 APIの負荷テストツールにGrafana Labs社が開発している「k6」というツールがあります。 k6はオープンソースのCLIツールですが、 「Grafana Cloud k6」というクラウドベースSaaSツールも提供されている便利なツールです。 ローカルのk6は、負荷テストの時に使ったことはあったのですが、真面目に負荷テストの設計をするにあたり、ちゃんと理解したかったため、改めて基本から調べてみました。k6の入門記事としてお役に立てれば嬉しいです。 インストール Macでは、k6を「Homebrew」でインストールすることができます。
Go製CLIツールGatling Commanderによる負荷試験実施の自動化 - ZOZO TECH BLOG
はじめに こんにちは、ML・データ部MLOpsブロックの岡本です。 MLOpsブロックでは機械学習モデルの実験基盤の作成、機械学習モデルを組み込んだAPI・Batchの開発・運用・保守を行なっています。APIを開発する際には負荷試験を実施し、本番環境で運用する際に求められるスループット・レイテンシを達成できるか確認します。 MLOpsブロックでの従来の負荷試験実施には人手を要する定型的な作業が複数ありました。また頻繁に行う作業でもありトイルとなっていました。 本記事ではMLOpsブロックで抱えていた負荷試験実施の課題と、解決のために開発したOSSのCLIツール、Gatling Commanderについて紹介します。Gatling Commanderが負荷試験の実施におけるトイル削減の一助になれば幸いです。 github.com 目次 はじめに 目次 背景・課題 従来の負荷試験実施の方法 分
eBPFを使った自動テストツール「Keploy」がすごい
この記事はKeployのバージョンv2.0.0-alpha53 を前提に執筆しております。 Keployとは KeployはeBPFを利用して取得できるWebアプリケーションの通信に関するトレース情報を元に、テストとそのテストの実行時に利用するスタブサーバーを生成することができるツールとなります。 公式サイトのトップには以下のようなスローガンが掲げられています。 2 minutes to 90% test coverage! テストに苦労した経験のある方は興味を惹かれるのではないでしょうか。 現在まだアルファ段階のプロジェクトですが、GitHubスター数は2683（2024/01/04現在）、CNCF Landscape にも掲載されているなど、一定の注目を集め始めているOSSです。 開発主体はプロダクトと同名のKeployというインド発のスタートアップで、去年GoogleによるインドのA
開発者を解き放て! Postmanが目指すAPIファーストな開発モデル 〜APIエコノミー、生成AI活用、開発の民主化まで
開発者を解き放て! Postmanが目指すAPIファーストな開発モデル 〜APIエコノミー、生成AI活用、開発の民主化まで 2023年12月5日、開発者向けAPIプラットフォームを提供するPostmanは「日本上陸記念イベント」を開催し、日本市場への本格的な参入を発表した。本記事では、Postman創業者 アビナフ・アシュタナ氏と、ウルシステムズ株式会社 漆原 茂氏の講演レポートを中心に、Postmanが目指すAPIファーストな世界観と、開発者にもたらされる変化について紹介する。 日本でも活発なコミュニティを オープニングでは、Postman株式会社 代表取締役社長 平林 良昭氏から、日本市場とコミュニティの概況について紹介された。 2014年にインドで創業したPostmanは、APIの構築・管理・テストのための開発者プラットフォームだ。2017年にアメリカに拠点を移し、2023年4月に日
Property-based Testing の位置付け / Intro to Property-based Testing
2023/12/20(水) https://findy.connpass.com/event/303813/
API仕様ファースト開発: 柴田 芳樹 (Yoshiki Shibata)
「API仕様ファースト開発」という用語は、私自身が雑誌「WEB+DB PRESS Vol.134」の特集1「実践API設計」を執筆する際に考えた造語です。 全く新規にサービスを開発する場合の開発順序は次のようになります（記事の題3章の図1）。 これは、私自身が初めてメルペイで担当して、一からマイクロサービスを開発したときの開発順序です。そして、その後、チーム移動により別のマイクロサービスの開発へ移動したり、カウシェへ転職したりした際に、最初に導入したのはE2Eテストフレームワーク（記事の第4章「E2Eテストフレームワークの構築」）でした。 そして、API仕様の技術的負債（エンドポイントの仕様が書かれていなくて、それをテストするE2Eテストもない状態）を返済するために、次の開発順序（記事の第5章の図1）を自分自身も行い、他の開発者達にも行ってもらうようになりました。 この開発プロセスが定着す
カジュアルに使えるスタブサーバとしてhttpstubとgrpcstubを作って使っている - Copy/Cut/Paste/Hatena
このエントリは Go Advent Calendar 2023 12 日目の記事です。 Goのテスティングパッケージで一番好きなパッケージは net/http/httptest です。 テスト実行時に実際にHTTPサーバを立ててHTTPリクエストを受けるというシンプルかつ強力なアプローチが良いです。 クライアント側にエンドポイントを変える仕組みさえあればクライアントのリクエストを受け付ける形でテストを構築することができるので、選択肢に入れておきたいテスト構成です。 ところで、私たちは runn （ランエヌ）というシナリオテスティングツールを開発しています。 github.com runnはHTTPクライアントでありgRPCクライアントでもあるのですが*1、そのrunn自体のテストのためにhttpstubとgrpcstubを作って使用しています。 httpstub github.com ht
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - Blazemeter/taurus: Automation-friendly framework for Continuous Testing by
Mock API Builder - endpts
