docker/compose は Go で書かれてるが、これのテストに gotest.tools というライブラリが使われていた。あまり見たことがなかったけど、使ってみたらわりと手触りがよかったのでここに記しておく。 gotest.tools はいつもの testing パッケージを拡張するようなライブラリ集。あとテストを実行するための CLI も提供している。GitHub Org は gotestyourself という名前だけど、これは洒落てるのかどうか不明(洒落てないほうに賭ける)。 assert, cmp gotest.tools/v3/assert が多分このライブラリのコア。主な API は assert.Check(t, comparison, msgAndArgs...) で、シグネチャを見たらあーそういうやつねと分かると思う。 予想通り comparison の中身しだい
いわさです。 先日、S3静的ホストで大量のリダイレクト設定をしていました。 設定の変更や追加をするたびにデグレードテストしないといけないなぁと思ったのでテストフレームワークでリダイレクト動作のテストを行うようにしてみました。 テストフレームワークにはTavernを使ってみました。 そこで、Tavernの使い方などを残しておきたいと思います。 なお、この記事ではmacOS Big Surで動作確認をしています。 Tavernとは Tavernは、pytestをベースにした、APIテストフレームワークです。 Tavern API Testing — Tavern 1.20.0 documentation Python Testing With Pytest | DevelopersIO 特徴としては、最小限の機能を備えていて、かつpytestと統合出来るという点でしょうか。 今回私は、cURL
はじめに Go 言語 + レイヤードアーキテクチャでテストコード込の REST API を作ったらとても勉強になったので共有します。 この記事が誰かの参考になれば幸いです。 今回のサンプルコードの最終形は僕の GitHub にあります。 レイヤードアーキテクチャとは? レイヤードアーキテクチャとは、システムの機能を責務ごとのグループ(レイヤー)に分割して隣り合うレイヤーとだけやり取りできるようにする仕組みです。 レイヤー同士の依存関係は上位から下位への1方向で統一されているのが特徴です。 レイヤー同士はインタフェースでゆるく結合されているため依存性を低く保つことができるというメリットがあります。 レイヤーの種類は一般的に以下のようなものがあります。 1 プレゼンテーション層: GUI や CUI などのユーザーインタフェース 2 アプリケーション層: アプリケーションロジック 3 ドメイン
はじめに 最近のエンジニアは毎日Vim pluginを書き、公開していると聞きます。 そんな大ブームの中、Vim pluginを作成するにあたって重要な要素が一つあります。 そう、テストです!テスト! Vim pluginをテストするにあたって便利なテスティングフレームワークはいくつかあります。 vader.vim vim-vspec vim-themis vroom etc... 今回はvim-themisを使った、便利なテストの書き方を紹介します。 注意 これは執筆段階では文書に記載されていない方法です。 執筆段階では、vim-themisのspec版の記述では、今回紹介する方法ができません。 また、今回はブラウザのフォントにより文字化けの恐れがあるので、hexでアイコンフォントを記載しています。 hexの値は以下のように読み返してください。 \ue62b \ue612 引用元 htt
この記事は、 Merpay Advent Calendar 2021 の10日目の記事です。 本記事は、1週間リリースを支えるAndroid自動テスト運用についてメルペイ Androidチームの@amane, @kenken, @anzai, @hiroPがお送りします。 自動化の背景 メルカリアプリでは、お客さまに素早く価値を届ける目的で、2週間に1度のアプリリリースサイクルを1週間に1度に短縮することを目指しました。(リリースサイクルのアップデートに関しては@stamakiさんのこちらの記事を参照してください。) しかしこのサイクルを実現するには、2日間かかっていたリグレッションテストを1日に短縮する必要がありました。 そこで手動で実施しているテストの工数を短縮するために、自動化を始めました。 Androidのリグレッションテスト環境の構築 メルペイではFirebase Test La
こんにちは。メルペイのフロントエンドエンジニアの @tokuda109 です。Merpay Tech Openness Month 2021 の13日目を担当します。 メルペイのフロントエンドチームは、管理している全てのサービスに対し E2E テストを継続的に実行しています。E2E テストの導入に関する取り組みについては「Cypress + TestRail による Frontend E2E テストの効率化について」で詳しく書かれています。 全てのサービスで E2E テストが導入されていますが、この記事で述べられているとおり、安定して動作しているわけではありません。テストが失敗することが多々発生していました。 本記事では、E2E テストがなぜ安定して動作しないかを調査し、どのように改善したかを紹介します。 背景 メルペイのフロントエンドチームは、テスト、パフォーマンス、アクセシビリティ、セ
Merpay Advent Calendar 2021 の 8 日目はメルペイフロントエンドチーム の @tanakaworld がお送りします。 はじめに メルペイは金融サービスであり、品質の維持・向上に日々取り組んでいます。フロントエンドチームでは、約 2 年前からリグレッションテストの自動化に取り組み始め、直近の 1 年間はインテグレーションテストの自動化にもチャレンジしてきました。本記事ではメルペイフロントエンドチームに於けるテスト自動化の方針とその全体像について振り返ってみたいと思います。 フロントエンドプロダクトに関わるテストは次のものが挙げられます。これらをひとつずつ順番に見ていきたいと思います。 ユニットテスト インテグレーションテスト シナリオテスト リグレッションテスト テストの種類とそのカバレッジ対象 1. ユニットテスト ユニットテストは Jest を用いて、主に
Merpay Advent Calendar 2020 の15日目は、メルペイスマート払いの開発を担当しているCredit Designチーム/Backend Engineer の 柴田 がお届けします。 はじめに 私が1984年に社会人になった頃は、ソフトウェア開発を行うためには会社に行くしかありませんでした。当時は、共用のVAXマシンで4.2/4.3 BSD Unixを使って開発していました。その後は、コンピュータハードウェアの発達に伴い、開発者ごとにワークステーションを用いて開発するようになり、デスクトップPCを用いた開発、そして今日のMacBook ProといったノートPCによる開発と時代が変わってきています。 2000年代には、安価で高性能なコンピュータの恩恵により、テスト駆動開発が徐々に広まってきました。そして、継続的インテグレーション(Continuous Integrati
LoadViewはクラウド環境から数千の同時接続を使用して、ウェブサイト、ウェブアプリ、APIをストレステストできるサービスです。・ LoadViewはクラウドベースの仮想サーバーを使用してサイトやアプリケーションにトラフィックを送信しますが、 これは、独自の負荷テスト環境(オンプレミス・クラウド)を維持するよりも、はるかに実用的でお財布にも優しくなる可能性があります。 マネージドなサービスなので、ネットワークやハードウェアのことは考えず、テストの設計と実行だけに専念することができます。 ウェブサイト、ウェブアプリ、Rest API、メディアストリームなど様々なテストソリューションが用意されています。 今回は使用感を知るために、ウェブサイトに対する簡単な負荷テストの実行を試していきたいと思います。 使ってみる 有料のサービスですが、 Free Trail で試します。 サインアップすると2
はじめに おはようございます、もきゅりんです。 長いお付き合いのある CloudFormation との関係が倦怠期に入ってきたため、CDK に手を出しております。 (きっと、またCFnとはラブラブになります) CDK といえば、避けられないトピックとなるのが、テスト方法です。 皆さん、どのようにテストしてますでしょうか。 自分は AWS のインフラ構築は比較的よく行っていると思ってますが、アプリ開発における単体テストや結合テストとかはゼロ知識です。 そんな自分ですが、これまでインフラ環境構築をしてきた中で、自分だったらどのへんをチェックすべくテストするかなぁと考えてみたのが本稿です。 *1 テストをまともに導入した経験もなく、CDK とのお付き合いもまだ浅いため、おかしな点、考慮不足点はいくらでもあるかと思いますが、ゆるくご指摘頂けたら幸いです。 加えて、今回紹介する進め方では実環境での
AWS CDKがGAされたので好きなサービスはAWS CDKと胸を張って言えるようになりました。 さてAWS DevDay Tokyo 2019でAWS CDKについてのセッションがありました。見ていない方はよろしければセッションレポートを見てください。 セッションの中でAWS CDKにおけるテスト方法について触れていました。今後自分でCDKライブラリを実装していく中でも避けられない内容なのでAWS公式ブログを見つつ実際に試してまとめてみました。 CDKのテストについて 今回記載するテストが指すものはCDKライブラリのテストです。 実際にライブラリが作成したCloudFormationテンプレートを元にCloudFormationスタックを作成するのはCDK CLIの責務です。 なのでCDK CLIから実際に作成するようなE2Eテストについては記載しません。またCDKライブラリのテストは通
テスト作業をスピードアップするために試すべき最高のテスト管理ツール: 「テスト管理」という用語は、テスターとして行うすべてのことを含み、このタスクを実行するために最高かつ効率的なテスト管理ソフトウェアの助けを借ります。 テスターの日常の活動には、次のものが含まれます。 リリース/プロジェクトサイクル/コンポーネント情報の作成と維持。 要件、テストケースなど、各リリース/サイクルに固有のテスト成果物を作成および維持します。 テスト資産のトレーサビリティとカバレッジを確立します。 テストの実行 サポート–テストスイートの作成、テスト実行ステータスのキャプチャなど。 分析のためのメトリック収集/レポートグラフの生成。 バグ追跡/欠陥管理。 テスト管理プロセスには、上記の一連のタスク/アクティビティが含まれます。このプロセスは、テスト作業全体が成功することを確認するために、重要で、詳細を重視し、役
115.テスターの一日 その⑥ 115.テスターの一日 その⑥ 探索的テスト セッションベースドの探索的テスト メンバーの得意不得意によって指示を変える 戦術っぽい話を思いついたままに書いてみる 「バグ登録はいつやればいいの」問題 「探索的テストで出したバグは再現が…」問題 「探索的テストのログを取りたい」問題 1分でわかるテスターちゃんができるまで! 探索的テスト 作者はテスト経験のほとんどがテスト部隊で、探索的テストも基本的にはチームプレイでやることのほうが多かったです。 探索的テストの全体設計をする人がいて、その人の指揮に合わせて進めるという形。 探索的テストをチームプレイで行うときはセッションベースドの探索的テストが管理がしやすく進めやすいです。 デメリットとして、指揮する人がテスト全体の状況が見えていない、状況から次の打ち手を考えられないと明後日の方向に連れていかれます。 無駄な
吉川@広島です。 テストでのデータベース単位の捉えかた - 日々常々 こちらの記事がはてなブックマークに上がっており、興味深く拝見していました。 テストに閉じたデータベース ここでのテストはテストメソッドのイメージです。テストインスタンスがクラス単位ならテストクラス単位でもいいんですが、とにかくテストの実行単位ごとに完全に独立したデータベースを使用します。 図はシンプルですが、テストケース数が100ならデータベース数も100になるイメージです。 すべての情報がテストに閉じている、理想の形です。実現できるならこれでいきたい。 荒唐無稽なことを言っているように感じるかもしれませんが、たとえばH2 Database Engineをインメモリでテストごとに名前を変えれば実現できます。 こちらの記述を見て、普段行っているLocalStack上のDynamoDBに対するJest自動テストにおいても活か
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く