@2024-06-24 さくらインターネット IaC 社内勉強会 LT
IaCにおけるテスト考察 / Tests in IaC
@2024-06-24 さくらインターネット IaC 社内勉強会 LT
インフラのテストに VPC Reachability Analyzer は外せないという話
人間の尊厳、幸福、アクセシビリティ / 第116回「WEB TOUCH MEETING」アクセシビリティSP
Playwright と Artillery によるパフォーマンステスト - Qiita
要約 DevOps や SRE を実践する人向けに、Playwright による E2E テストを Artillery の負荷掛けシナリオとして利用する手法についてハンズオンを交えて紹介します。 課題としては、Playwright で自動生成したスクリプトを手直ししないと難しいパターンがあることを挙げています。 その他、Tips もあります。 はじめに NSSOL Advent Calendar 2022 の 13 日目にも投稿しました、とうふです。 先の記事で軽く説明した通り、私がいま参画している案件では E2E テスト用のスクリプトを流用したパフォーマンステスト を行なっています。 本記事では、Playwright で作成した E2E テストスクリプトを使って負荷掛けを行うことでパフォーマンステストを実施する手法について紹介します。 前提知識 Playwright とは Playwri
Playwright testをLambdaコンテナ上でRICを使って動作させる - Qiita
概要 Lambda関数は通常Amazon Linux上で動作していますが、Playwrightは公式ではDebianとUbuntuしかサポートしていません（参考）。 そのため、Lambda Runtime Interface Client(RIC)を使ってDebian上のNode.jsのベースイメージを元にPlaywrightをインストールすることでLambda上で動作させました。 ローカルで動作確認したいためAWS Serverless Application Model(AWS SAM)で構築しています。 ソース類は以下にまとめています。 https://github.com/octop162/playwright-lambda SAM準備 sam init で初期化しtemplate.yamlを生成しました。 メモリ使用量を1024MB, タイムアウトを最大の900秒に設定しています
AWS LambdaでPlaywrightを使う(Python 3.10 + playwright1.42.0) - Qiita
スクレイピングにseleniumを使用していましたが、playwrightがかなり直感的で使いやすかったことから活用を始めました。また、実行環境をlambdaにすることで他のアプリケーションから利用しやすくすることもできるため、その方法をまとめておきます。 開発環境 Windows10 Home 22H2 Python 3.10.4 playwright 1.42.0 1.playwrightを利用した機能を実装する ローカルで普通に実装します。ブラウザオブジェクトを作る際には次のオプションを指定しておきます。今回は図書館のHPにアクセスして貸出状況を取得するスクレイパーを実装しています。 browser = playwright.chromium.launch( args=[ "--disable-gpu", "--single-process", ], ) 2.lambdaから利用する
AWS Chalice で実装したアプリケーションのユニットテスト - Qiita
AWS Chalice とは AWS SDK for Python を開発するチームによってメンテナンスされている、AWS Lambda に展開するアプリケーションを実装するための Python のマイクロフレームワークです。 ビルトインされている @api.route, @app.on_s3_event などのデコレータを用いて関数を実装し、CLI で簡単にそれらを実際に AWS 上に展開することが出来るようになります。 例えば、chalice CLI の中にある chalice new-project コマンドでプロジェクトの雛形を作成するとこのような実装が生成されます。 from chalice import Chalice app = Chalice(app_name='test') @app.route('/') def index(): return {'hello': 'wo
AWS SDK Rubyでスタブを行う - Qiita
はじめに AWS SDKを使用したコードに対してテストを記述したい場合、AWSのSDKで用意されているClientStubsを使用して、スタブを行うことが可能です。 ドキュメント自体は公式が出しているものがありますが、この例だけではやりたいこと（Aws::S3::Client以外のインスタンスを使うケース）が実現できなかったので、今回調べたことについてまとめました。 環境 Ruby: 2.7.1 aws-sdk: 3.1.0 aws-s3-sdk: 1.114.0 公式ドキュメントから このドキュメントにあるようにAws::ClientStubsというモジュールが、各サービスに対応したClientクラスにincludeされています。 今回はS3を使って、その例を紹介します。 このモジュールに定義されているのはapi_requests, stub_data,stub_responsesの３つ
Dynamo DB ベースのアプリケーションをmotoとfactory_boyを用いてユニットテストする - Qiita
boto3 は AWS SDK の Python パッケージで、Dynamo DB などの AWS のサービスを呼び出すのに使います。 この boto3 には moto という mock パッケージがあります。 moto を使うと、テストを実行するとき Dynamo DB のスタブにテスト用のデータ(fixtures)を 返させることができるので、テーブルが存在していなくてもテストケースを通すことができます。 本稿では、moto を使って Dynamo DB に依存せずにアプリケーションをテストする方法を紹介します。 さらに、factory_boy を使って fixtures の組み立てを共通化する方法も紹介します。 factory_boy は fixtures の組み立てを担う Factory クラスを備えたパッケージです。 なお、本稿ではアプリケーションとして Flaskベースの AP
mysql の CHECKSUM TABLE が 自動テストのDBロールバックする時に便利だった - Qiita
はじめに 去年は、言語バージョンアップにおけるE2Eテストの考え方とアプローチ方法についてを書きました。 今回は、「DBの差分とロールバック」 に関して書きたいと思います。 DB Diff を実際に使ってみた結果 前回の記事では、「DB Diff」というツールを使うことで、比較とロールバックを自動で行うことができると書いていました。 ★E2Eで検証するデータ種類によって比較方法 新規登録で同じデータが登録される。 → 「どのテーブルに変更が加わったのか？」は DBデータファイルの更新日時等から自動取得させる。 → 登録されたDBデータの差分の比較。( DB Diff ) → 比較後にテスト実行前の状態に戻す( DB Diff ) とある問題が発生し、本格的な導入を断念することにしました。 レコードが多いテーブルの比較を行う場合に時間がかかり、テスト実行後のデータロールバックに時間がかかりす
moto によって requests が意図せずモック化されてしまう問題を回避する - Qiita
moto は、AWS SDK の mocking パッケージです。 moto を用いたユニットテストについては以前 エントリを書きました。 このなかで触れましたが、requests パッケージが意図せずモック化されてしまう問題があります。 この問題の回避策について自分なりのアプローチをまとめておきます 問題としては、moto でスタブをアクティブにすると その後の requests パッケージによるリクエストがすべてモック化されてしまうというものです: これにより、elasticsearch-py など requests に依存したパッケージにおいてHTTPリクエストのさいにエラーが起きることがあります。 回避策 回避策としては、moto の responses_mock にパススルーする URL を登録します:
S3などのデータストアへのアクセス機能をモックとすることでデータストアなしでユニットテストする手法( Java, Mockito ) - Qiita
S3などのデータストアへのアクセス機能をモックとすることでデータストアなしでユニットテストする手法( Java, Mockito )S3unittestMockitoaws-sdkMock 概要 データストアにアクセスすることなくテストを可能とするポイントを紹介します。 データストア( 今回はS3 )にアクセスするオブジェクトを、外部からテスト対象クラスに注入可能としておく テスト時は、データストアにアクセスしないモックを注入する 動作確認可能なソースコードは loftkun/spring-boot-s3-mock-example にあります。 テスト対象クラス テスト対象のクラスです。S3にアクセスするclientを外部から注入できるようにしています。 ( この例ではコンストラクタで受け取っています。 ) このようにデータストアにアクセスするオブジェクトを、外部からテスト対象クラスに注入
サービステストをLambda+unittest用ライブラリで実装してみる - Qiita
AWS LambdaとServerless Advent Calendar 2020 3日目の記事です。 あるサービスのテスト(外部サービスとの結合テスト)を、Lambda(python)+unittestで実装してみます。 やること 「特定の条件を満たすメールを受信した場合はBacklogに課題を起票する」というサービスをテストするエンジンをLambda+unittestで構築します。 unittestライブラリをunittestよりも上のレイヤーの試験に使います。案外使い心地がいいです。 テスト対象サービス 以下の条件を満たすメールを受信した場合に、Backlogに課題を起票します メールタイトルに特定の文字列を含む 送信元が許可された特定のメールアドレス テストエンジン Lambda(python)にunittestライブラリでテストシナリオを記述し実行 各テストケースは、概ね以下の
pythonでS3をモック化できるStubberを使って単体テスト - Qiita
記事について pythonでS3をモック化する際に、以前はpython標準のMockを使っていたけど、boto3に標準のStubberという便利なモジュールが用意されているので、使用してみた。 なお、コードは、実際に動かしたものを公開用に修正したもので、動作確認はしておりません。ご了承ください。 環境 python３系 boto3 テストコードを書いてみる S3からオブジェクトをGETする 対象コード import boto3 func_get(): s3 = boto3.resource('s3') bucket = 'bucket' key = '/key/object.json' obj = s3.Object(bucket, key) res = obj.get() return res from botocore.stub import Stubber from botocore
simulatorを使ったCloudFunctionsのunit testを安定化・爆速化させる - Qiita
こんにちは。virapture株式会社のもぐめっとです。 みんなで集合写真をとったのですが、何故か僕だけぶれてました。何歳になっても落ち着かないみたいです。 今日もfirebase大好きっ子が、firebase大好きっ子向けにfirebaseの情報を提供していこうと思います。 これはFirebase Advent Calendar 202123日目の記事です。 概要 本日はcloud functionsでunit testを書く際の方法として、Cloud Functionsのemulatorを使わないという選択肢とその利点と留意点について紹介します。 目標 cloud functionsのunit testを爆速にして荒ぶるCIを安定させます。 ただし、あくまで今回紹介するのは方法の一つです。 後述するデメリットはあるので必要に応じて取捨選択をしてください。 なぜCloud Functio
Snowflake x Terraformに自動テストを導入した話 - Qiita
はじめに こんにちは。ARISEでデータ基盤構築業務を主に行う「データアーキテクト」というキャリアトラックに所属しているエンジニアの田畑です。先日当社のテックブログの記事でも触れましたが、現在私はSnowflakeでの大規模データ基盤構築に携わっています。 そのプロジェクトにおいて、データ基盤のインフラ面における品質担保の負担軽減を図るべく、自動テストを導入しました。今回はその経緯や実装概要、今後の展望を共有したいと思います。 前提 SnowflakeはPRD, STG, DEVの3面構成(アカウントレベルで分離) Snowflakeのオブジェクトは基本Terraformで管理 TerraformコードのリポジトリはGitHubで管理 リポジトリはGit-flowで開発 各環境に対応するブランチに対してPR作成をするとterraform plan, マージをするとterraform app
AWS Amplify Consoleを連携させてテスト結果ページを自動生成・管理する - Qiita
本記事は、Qiita Advent Calendar 2019 - AWS Amplifyの10日目の記事です。 タイトルでは表現しづらい内容ですが、やりたいことは下図の通りです。 Amplify Consoleを利用してテスト／ビルドできるようにしていたら、テスト結果も自動的に蓄積されて参照可能な形にできないか、、、と思い始めて手を動かした結果です。 やりたいことの流れ 以前開発したCognito管理Web画面のビルドをAmplify Consoleで行う。 https://github.com/kojiisd/cognito-user-manager/tree/master そのAmplify Consoleのビルドの中でKarateやunittestによるE2Eテスト、単体テストが実施される。 E2Eテスト、単体テストの結果を別の試験結果保存用WebサイトのGithubリポジトリにP
CodeBuildでREST APIの自動テストを実行する - Qiita
この記事は AWS Advent Calendar 2021 14日目の記事です。 概要 AWSでCI/CDパイプラインを構築する場合、マネージドサービスであるCodeシリーズを利用することが多々あります。 その中でも、ビルドを実行するCodeBuildでは自動テストのツールを組み込むことが可能です。 この記事では、CodeBuildでREST APIの自動テストを実行する方法を紹介します。記事の開発言語はPythonですが、REST APIのテストは言語に依存しないメリットがあるので、他の言語やフレームワークを使っている方にも参考になればと思います。 REST APIの自動テストツールとしてはKarateを利用します。 前提知識のある方は「CodeBuildの設定」だけ読んでいただければ、大まかな内容は掴めると思います。 2021/12/15 追記 利用したソースコードはgithubに上
EventBridgeScheduler+ECS+Docker+SeleniumでWebサイトのスクリーンショットを定期的に撮影する - Qiita
EventBridgeScheduler+ECS+Docker+SeleniumでWebサイトのスクリーンショットを定期的に撮影するSeleniumAWSDockerECSEventBridge EventBridgeScheduler, ECS, Docker, Seleniumを使い1時間ごとに阿部寛のHPのスクリーンショットを撮影しS3に保存する方法についてまとめました。 スクレイピング用のDockerイメージを作成 以下の記事を参考にしながらスクレイピング用のDockerイメージを作成します。 環境変数からスクレイピング先のURLと保存先のバケットを読み取ります。 参考: Selenium×dockerでテスト自動化してみた FROM --platform=linux/x86_64 python:3.12.1-alpine3.19 ENV PYTHONIOENCODING utf-
serverspecをコンテナに格納してお手軽インフラテスト自動化 #STIG #PCI-DSS #CISベンチマーク - Qiita
まとめ InSpecコマンドとテストコードをコンテナイメージに入れて、いつでもどこでもインフラテストを実行できるようにします。 Docker Hubで公開されているchef/inspecは、CPUアーキテクチャのARM対応していないなど不具合が発生しがちなので、Dockerfileで自前でInSpecコンテナを用意するのが近道です。 FROM ubuntu # Mixlib-install gem で InSpecをインストール RUN apt update -yq && apt install -yq ruby git nginx RUN gem install -N mixlib-install && mixlib-install download inspec -v 5 RUN dpkg -i inspec* ## ライセンス回避 RUN echo 'export CHEF_LICE
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWS を使ったシステムのテスト方針 #jawsug #jawsug_niigataken #nds60
