TerraformのChecksとTestsの使い分け | DevelopersIO
1. テスト用の一時的なリソース作成の有無 Testsはテスト実行時に、テスト用のリソースを一時的に作成することができます。 上記の何が嬉しいかというと、直接リソースを作成しない(※)モジュールでテストが行いやすいです。 tfファイルを直接みる静的解析に比べて、ApplyやPlanを伴うテストの方が得られる情報は多いため踏み込んだテストができます。 呼び出し側でテストをする場合、関連するリソースの数が多く1回あたりの実行に時間がかかります。 全体に比べて作成するリソース数が少ないため、Testsはモジュール単位でテストを行うことに適しています。 ※ディレクトリで直接terraform applyを行わない。他tfファイルから呼び出して、リソースを作成する。 2. ライフサイクルの外側でのチェックの有無 Terraformの設定ファイルだけでは、ステータスがわからない項目もあります。 例えば
テストを自動化するのをやめ、自動テストを作ろう
July Tech Festa 2020 TrackB https://jtf2020.peatix.com/
自動テスト全体の信頼性を維持するためにはどうするか 「ブレない基準でピラミッドを作り、スモールに切り出していく」
Qiita Conferenceは、ソフトウェア開発者が集まり、最新の技術や最先端の挑戦・ソフトウェアの未来についての考えや知見を共有し、つながる場を創出する、「Qiita」が開催するオンライン技術カンファレンスです。ここで和田卓人氏が「サバンナ便り - 自動テストに関する連載で得られた知見のまとめ（2023年5月版） 」をテーマに登壇。最後に、テストダブルとテストピラミッド、サイズダウン戦略について話します。 テスト用に使う偽物「テストダブル」 和田卓人氏：じゃあ次。テストダブルの話にいきます。「忠実性と決定性のトレードオフを理解しよう」という点です。これはもうちょっとあとにまた出てきます。 テストダブルというもので、モックオブジェクトとかスタブとかを使って、本物ではない偽物をテスト用に使ってテストをすることはよくありますよね。 データベースの偽物とか外部システムの偽物とか、Amazon
「開発における安全と効率の両立を追求したい」 静的解析・ユニットテスト・E2Eテストにおける、ディー・エヌ・エーの「Shift Left戦術」
インターネットやAIを駆使しながら、領域に捉われずにさらなる挑戦を行うDeNAの取り組みを紹介する「DeNA TechCon 2023」。ここで認証認可システムのリノベーションチームの岸直輝氏が登壇。Shift Leftの考え方を基に実践している静的解析や自動テスト、挙動の差分を自動で発見するための取り組みについて紹介します。全2回。後半は、各フェーズにおける、静的解析・ユニットテスト・E2Eテスト、それぞれの取り組みについて。前回はこちら。 静的解析のメリットとデメリット 岸直輝氏：では、ここからは今お話ししたShift Leftの具体的な取り組みについて見ていきましょう。ここでは、各フェーズごとに対応する取り組みを、静的解析、ユニットテスト、E2Eテストの3つに分けて紹介します。 まずは静的解析について。静的解析は、プログラムを実行することなく、静的にさまざまな異常を検出する手法です。
滑らかなDevOpsを実現するE2Eテストの構築と運用
はじめに 「HRMOS タレントマネジメント」（以下、「HRMOS」）では1年間かけて、自動 E2E テストの導入から開発・運用をしてきました。 最終的には、画像のように ChatOps でいつでも簡単に開発者が E2E テストを実行できる環境が整備されました。 この記事では、1年間で溜まった知見をもとに主に以下の内容に触れていきます。 「HRMOS」における自動 E2E テストの導入の理由 自動 E2E テスト（Autify）の導入までの道筋 自動 E2E テストの DevOps 連携 自動 E2E テストの活用による品質担保 自動 E2E テストの導入や、その活用法に悩んでいる方の助けになれば幸いです。 「HRMOS」における自動 E2E テストの必要性 「HRMOS」では日々ユニットテスト、インテグレーションテストなどの様々なテストが CI で動いています。 加えて、開発者も bra
フロントエンド開発のためのテスト入門 - サンプルの紹介 -
昨年から執筆を続けていた書籍が 4/24 に刊行します。「フロントエンド開発のためのテスト入門」という本です。 書籍ならではのテストコード解説を目指して 次の投票結果は、書籍企画時に持ち込んだ筆者のツイートです。フロントエンドテストに関していえば、8 割近くの方が何かしら不安や不足を感じている、という結果になりました。 不安や不足の原因は様々なものがあるかと思います。そのうち、筆者が着目したのは「テスト手法の豊富さ」です。「単体テスト・結合テスト・E2E テスト、何をどれほど書けばよいのか？」という疑問は、フロントエンドに限らず、はじめて自動テストに取り組まれる方が通る関門ではないでしょうか。 自動テストを書くには「テスト対象」を明確にしたうえで、テスト対象に適したテストコードを書く必要があります。本書は、現場で書かれるものに近い「テスト対象 = アプリケーションコード」をサンプルとして用
[アップデート] AWS Resilience Hub が Terraform, ECS などを追加サポート | DevelopersIO
ちゃだいん（@chazuke4649）です。 少し前のアップデートになりますが、 AWS Resilience Hub が Terraform,Amazon ECS,Route53,AWS Elastic Disaster Recovery、AWS Backupのサポートを追加しました！ AWS Resilience Hub が Terraform、Amazon ECS、および追加サービスのサポートを追加 AWS Resilience Hub は、Amazon Elastic Container Service (Amazon ECS)、Amazon Route 53、AWS Elastic Disaster Recovery、AWS Backup、および Terraform をソースとしてアプリケーションをアップロードする機能をサポートするようになりました。このように対応リソースを拡大す
![[アップデート] AWS Resilience Hub が Terraform, ECS などを追加サポート | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/c98e8f5c284e8f71935ed4aef8a3e94ab822f8dc/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2022%2F04%2Famazon-resilience-hub.jpg)
性能評価の指標を合わせる方法 - pTune.jp
「1万ユーザーの同時アクセスに対応できるようにして欲しい」という要望を受けることがあります。 このようなケースでは、負荷テストをお勧めすることが多いのですが、負荷テストで確認できるのは「秒間のリクエスト数」です。「1万ユーザーの同時アクセスに対応できること」を証明するためには、「1万ユーザーの同時アクセス」をブレイクダウンして、「秒間のリクエスト数」に落とし込む必要があります。 この記事では、「1万ユーザーの同時アクセス」を「秒間のリクエスト数」に落とし込む方法を説明します。 「1万ユーザーの同時アクセス」を「秒間のリクエスト数」に落とし込む 秒間のリクエスト数を計算するためには、次の式を使います。 秒間のリクエスト数 ＝ ユーザー数 × ページ/ユーザー ÷ 想定時間(秒) × ピーク特性 それぞれについて、説明していきます。 ユーザー数 アクセスしてくる可能性がある、ユーザーの総数を確
同じソースツリーでテストが通っていたらテストをスキップする | おそらくはそれさえも平凡な日々
tl;dr git rev-parse HEAD^{tree} でツリーオブジェクトのハッシュ値が取れるので、ブランチが異なる場合でも同じソースツリーであるかどうかを判定できます。 これを利用して、すでにテストを通ったtreeのハッシュ値をどこかに記録しておいて、同一のソースツリーに対するテストをスキップできます。 本題 よく使われている、develop/mainブランチ運用をしている場合に、ちょっとした修正を本番に入れたい場合には以下のようなフローを踏むことになるでしょう。 featureブランチをdevelopブランチの先頭から切って修正を作ってテストが通るのを待つ developブランチにfeatureブランチにマージしてテストが通るのを待つ mainブランチにdevelopブランチをマージしてテストが通ったらdeployする さて、この時、他の作業が混ざらない限りにおいては1,2,
Exploration Through Example
Thu, 21 Aug 2003 Some random links Martin Fowler ... But I think these arguments, while valid, have missed another vital reason for direct developer-customer interaction - enjoyment... Michael Hamman ... they had never before realized that physical space could have such a subtle impact on human behavior... Laurent Bossavit ... An idiom, in natural language, is a ready-made expression with a specif
アジャイルテスティングはどこをテスト自動化するべきか - Qiita
アジャイルテスティングとは アジャイル開発の中でのテストのことですが、 アジャイルテスティングは、ドキュメントへの依存度がより少なく、変化をより多く受け入れ、プロジェクトが品質について継続的に会話をするという考え方のテスティングスタイルである。 Brian Marick 引用元: アジャイルソフトウェア要求 らしいです。 【しかし】アジャイルテスティングの時間がねー問題 参考：QA challenges with agile software development ドキュメンテーションの優先順位が低く、エラーが発生する可能性が高くなり、最終的QAチームにより作業時間に圧力がかかる 新機能は迅速に導入される為、テストチームが最新機能が要件に合ってるか、ビジネスルールと合致しているか、を確認する時間が短い テスターは開発者の役割も半分担う場合がある(テスト自動化...etc)為、時間がない
テストを書くか書かないかの状況判断 / Deciding whether to write tests - DeNA Tech Talk
2014/12/09 に DeNA 社内勉強会にお招きいただいて話した内容です
REST API用のファジングツール “RESTler” で始めるお手軽ファジング | IIJ Engineers Blog
IIJイノベーションインスティテュートの四谷です。普段はWeb API開発の生産性向上についての調査や開発を行っています。 今日はREST APIのテスト効率を改善するツール「RESTler」を紹介します。 RESTlerについて RESTlerはMicrosoft Researchが開発し、OSSとして公開しているREST API用のファジングツール（ファザー）です。 ファジングはネットワークプロトコルの実装等、もう少し下位レイヤーでの活用が主で、APIに対して実行できるファザーは数少ないのですが、その1つがRESTlerです。Microsoftでは実際にRESTlerを使用して、AzureやOffice365のバグを検出したそうです。 特長 RESTlerの最大の特長は、OpenAPIドキュメントとして記述されたAPI仕様さえあれば、自動的にテストケースが生成され、ファジングを実行でき
モックは必要悪で、しないにこしたことはない - blog.8-p.info
Mockito や gomock が使いやすいせいか、単体テストというのはモックするものである、という思い込みがあるのか、人々がモックしすぎているのを時折みかける。 モックは必要悪で、しないにこしたことはない。外部の API サーバーとかはガンガン叩くわけにもいかないけれど、ファイル読み書きくらいは、実際にファイルを作ったり消したりしてしまっていい。/etc/passwd を消すとか、1GB のファイルを作るとかだと難しいかもしれないけれど、その場合でも、パスのプレフィックスを指定できるようにして、一時ディレクトリの中の etc/passwd を使うとか、ファイルサイズを指定できるようにするとか、逃げ道はいくつもある。そこを飛ばして「ファイル操作は一律モックしましょう」とか頑張りだすと辛いことになりがちだ。 モックの一番の問題は、本番とテストで違うコードが走ることで、これは自動テストの価値
AWS Device Farmでデスクトップブラウザテストを行う | DevelopersIO
いわさです。 AWS Device FarmはAWS上でホストされているデバイスでテストを行うことが出来るサービスですが、モバイルだけでなくデスクトップブラウザでもテストを行うことが出来ます。 最近Device Farmのデスクトップブラウザ機能にアップデートがあったので試してみたかったのですが、そもそもDevice Farmでデスクトップブラウザテストを実施したことがなかったので本日はまずそこから始めてみました。 デスクトップブラウザテストの仕組み Remote WebDriver モバイルデバイスでテストを実施する場合はAppiumを使ったテストコードをDevice Farmへアップロードし、クラウドでホストされたデバイスをターゲットにDevice Farm上でテストコードが実行されます。 これについては以前ブログ記事にしています。 デスクトップブラウザの場合は、SeleniumのRe
実践リスクベーステスト-PRISMAメソッド-
1.イントロダクション システムテストフェーズに入る前の工程、つまり開発や単体、結合テストが遅延することはよくあることです。 その結果、システムテストフェーズにしわ寄せがゆき、大きなプレッシャーの中でテストを実施しなければなりません。 しかし、テストをすること自体をやめたり、遅らせたり、ましてや手抜きテストなどできません。 実際のプロジェクトでは限られたリソースの中で最良のテストを実施するために、テストすべき対象を優先順位付けします。 「システムのどこが最も注意しなければいけない部分ですか？」 答えは1つではありません、どの部分をテストするかという優先順位付けはリスクベースでなければなりません。 テストにどれだけリソースをかけられるかとテスト後に欠陥が発見された場合のコストとの間には関係がります。 リスクによっては段階的な本番リリースする場合もあります。 段階的リリースでの一般的なテストア
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JMeter Cloud Load Testing | Blazemeter by Perforce
Using Models to Help Plan Tests in Agile Projects | Agile Testing Quadrants | InformIT
アジャイルテスト -高品質を追求するアジャイルチームにおけるテストの視点-
アジャイルで開発したシステムをいざテスト→全然使えない！ を防ぐ、テストの考え方総まとめ
