1 - 40 件 / 150件
最近、ふとした気づきがありました。 それは、「同じものを見ていても、過去と現在の自分では見えている世界がまったく違っている」ということです。 みなさんには、このコードからどんな世界が見えますか? async function getUserName(userId) { const response = await fetch(`https://api.example.com/users/${userId}`); const user = await response.json(); return user.name; } はじめに こんにちは、株式会社ココナラ在籍のKです。 本記事では、冒頭の5行のコードを通して、私たちが学ぶ理由について考えてみたいと思います。 TL;DR 同じコードを見ても、人によって見えるものが違っている 学習を重ねることで、それまで見えなかった世界が見えてくる 学習
世界中のITエンジニアが悩まされている原因不明でテストが失敗する「フレイキーテスト」問題。対策の最新動向をJenkins作者の川口氏が解説(前編)。DevOps Days Tokyo 2022 世界中のITエンジニアが悩まされている問題の1つに、テストが原因不明で失敗する、いわゆる「フレイキーテスト」があります。 フレイキーテストは、リトライすると成功することもあるし、失敗する原因を調べようとしてもなかなか分かりません。GoogleやFacebookやGitHub、Spotifyといった先進的な企業でさえもフレイキーテストには悩まされています。 このフレイキーテストにどう立ち向かうべきなのか、Jenkinsの作者として知られる川口耕介氏がその最新動向を伝えるセッション「Flaky test対策の最新動向」を、4月21日、22日の2日間行われたイベント「DevOps Days Tokyo 2
このブログエントリでは、テスト駆動開発(TDD: Test-Driven Development)の考案者Kent BeckがTDDの定義を改めて明確化した文章を、許可を得たうえで翻訳し、訳者の考察を沿えています。 きっかけ 2023年の年末、テスト駆動開発(TDD: Test-Driven Development)の考案者Kent Beckは、substackにTDDに関するポストを連投して論戦を繰り広げていました。TDDはその誕生から20年以上が経ち、その間に「意味の希薄化」が発生して議論が噛み合わなくなっていました。意味の希薄化(Semantic Diffusion)とは、新しく作り出された用語が広まる際に本来の意味や定義が弱まって伝わる現象です。 私(和田)はTDDと関わりの深いキャリアを歩んできました。Kent Beckの著書『テスト駆動開発』の翻訳者であることもあり、TDDの正
2022年9月9日にこんなツイートをしたところ、 ソフトウェアテストの書籍・資料について、こういうマップを作ってみたい。「QA関連」でできるといいんだけど、縦軸が定まらない。 一番繰り返し読んでいるドリル本をサンプルにしてみたけど、テスト分析自体がすでに初級じゃない気もするから、色付けも難しい。うーん。 誰か一緒にやりません?w pic.twitter.com/R0lVJhcpkD— Kazu SUZUKI (@kz_suzuki) 2022年9月9日 「一緒にやってもいいよ〜」っていう方々に声をかけていただき、1週間あまりでみるみるできあがっていきました! みなさんの機動力高すぎて、わたしの寄与は「声をかけて最初のフォーマットを作った」くらいになってしまいましたよ。 ということで、以下に公開します! docs.google.com 「閲覧者(コメント可)」というアクセス権を設定しています
MIXI(旧社名ミクシィ)は5月8日、同社の新入社員向け技術研修で使用した資料を無償公開した。分散型バージョン管理システム「Git」とテスト・設計研修の資料をスライド共有サービス「Speaker Deck」で公開中。動画も後ほど公開するという。 Gitの研修資料は約470ページあり、Gitを使ったチーム開発の進め方やGitの内部構造などを記載している。テスト・設計研修の資料は約40ページ構成で、テスト技法やコードレビューのコツなどを紹介。いずれの資料も同社の社員が作成した。 同社は2021年から新入社員向け研修の資料を一般公開しており、22年はUnityでのゲーム開発やAI、セキュリティ研修など全12種類の資料を自社ブログに掲載していた。同社の公式Twitter(@mixi_engineers)は「今後も随時資料や動画を公開していく」としている。 関連記事 ミクシィ、技術カンファレンスを初
概要 本書を通して、ソフトウェアテストの知識・技術を体系的に学びます。そしてその中でテストによって次の課題にどのように対応していくか学び、現代的なソフトウェア開発に対応するため総合力・基礎力を強化します。 開発成功や顧客満足実現をどう支えるか 開発の高品質と高スピードの両立を支えるアプローチとは アジャイルや継続的デリバリー、DevOpsの導入にどう対応するか テスト自動化といったテスト技術導入を成功させるには チーム全体でテストを推進していくためには 定番のテスト失敗要因に対しマネジメントでどう対策すべきか こんな方にオススメ テストエンジニアやQAエンジニアにこれからなる人 テストに疎いが、テストに関わることになった開発者やマネージャ 旧来のテストと、モダンな開発現場で求められるテスト技術のギャップに悩んでいる人 個々の担当ごとのテストの遂行はできているが、それらを連携させた、チーム全
Mockito や gomock が使いやすいせいか、単体テストというのはモックするものである、という思い込みがあるのか、人々がモックしすぎているのを時折みかける。 モックは必要悪で、しないにこしたことはない。外部の API サーバーとかはガンガン叩くわけにもいかないけれど、ファイル読み書きくらいは、実際にファイルを作ったり消したりしてしまっていい。/etc/passwd を消すとか、1GB のファイルを作るとかだと難しいかもしれないけれど、その場合でも、パスのプレフィックスを指定できるようにして、一時ディレクトリの中の etc/passwd を使うとか、ファイルサイズを指定できるようにするとか、逃げ道はいくつもある。そこを飛ばして「ファイル操作は一律モックしましょう」とか頑張りだすと辛いことになりがちだ。 モックの一番の問題は、本番とテストで違うコードが走ることで、これは自動テストの価値
はじめに この記事は レガシーコード改善ガイド: 保守開発のためのリファクタリング を参考に手を動かしてみて、ある程度自分の中で体系的にまとまった知識のアウトプットです。 この記事で扱う内容 この記事で扱うのは主にレガシーコードで単体テストを書く際のハードルになりがちな 依存関係の排除 に関する手法を紹介します。 この記事を読んだ後に、 『この観点を持っておけば単体テストをスムーズに書いていけそう!』 『今までモック使ってたけど意外とモック使わなくても書けるね!』 となったらいいな、と思います。 ちなみに、今まであんまりテスト書いたことないよーて人は以下の記事など参考にして一度やってみてください。 もくじ テスト駆動不具合修正 or リファクタリング手順 なぜテストが書けないのか 依存関係を排除できればテストは書ける 依存関係を排除するためのカギになる考え方 書けない単体テストがなくなる2
こんにちは、SWETグループの田熊です。 現在SWETグループでは書籍「単体テストの使い方/考え方」の輪読会を実施しています。 輪読会ではメンバー同士で活発に意見が交わされていますが、著者の主張に疑問を感じる箇所もあり、一度グループ外の方とも意見を交換したいと考えていました。 そこで、t_wadaさんをお招きし「単体テストの使い方/考え方」についてディスカッションする機会を設けました。 本記事では、SWETメンバーとt_wadaさんとのやりとりを紹介したいと思います。 ディスカッションの流れ ディスカッションは事前にSWETグループのメンバーが書籍を読んで疑問に感じたテーマを挙げてもらい、t_wadaさんの意見を聞くという流れで行いました。 今回は次のテーマについて話をしました。 「退行に対する保護」があるテストとはなにか 「リファクタリングへの耐性」のトレードオフはあるのか 統合テストの
「アジャイルサムライ」の著者が語る、技術志向の企業が世界をどう見ているのか? そしてソフトウェアテスト自動化を進化させる方法について(前編)。JaSST'22 Tokyo基調講演 Jonathan Rasmusson(ジョナサン・ラスムッソン)氏はアジャイル開発における著名人の一人であり、さまざまな先進的ソフトウェア企業において開発やテストに携わってきました。 日本ではアジャイル開発の入門書として話題となった書籍「アジャイルサムライ」(オーム社,2011)や「初めての自動テスト」(オライリー,2021)、「ユニコーン企業のひみつ」(オライリー,2017)の著者としても有名です。 そのラスムッソン氏が2022年3月10日と11日の2日間、ソフトウェアのテストに関わる国内最大のイベント「ソフトウェアテストシンポジウム 2022 東京」(JaSST'22 Tokyo)の基調講演に登壇しました。
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 〜Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より 今回、Software Design 2022年3月号 第2特集「そろそろはじめるテスト駆動開発 JavaScriptでテストファーストに挑戦」の第1章「保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像」を本サイトに掲載します。第2章以降については、本誌『Software Design 2022年3月号』電子版(Gihyo Digital Publishing、Amazon Kindle)をご購読いただければ幸いです。 第1章では、混同されることの多い自動テスト関係の概念を、自動テスト、テストファースト、テスト駆動開発の3つの段階に分け、それぞれの効果や注意点を説明します。ソフ
AI に自分のスタイルでコードを書かせたい。 自分のコーディングスタイルを端的にまとめると、たぶんこう。 TDD でミニマルにはじめるのが好き でも DDD で段階的にドメインモデリングもしたい 実装は関数型ドメインモデリングに寄せる これをAIに叩き込みたい。資料を読ませてプロンプトを作って、それにそって実装させる。 エヴァンスのDDDと軽量DDDの2つでやらせてみる。 コードはここ 自分のコーディングスタイルに合わせたプロンプトを作成する MCPエージェントで検索とURL展開を使える状態で次のように指示をした。(自作ディープサーチみたいなもの) インターネットでDDDについて調べさせる インターネットで関数型ドメインモデリングについて調べさせる インターネットでTDDについて調べさせる プロンプトとして使えるように要点を圧縮しろ 端的に圧縮しろ もっと圧縮しろ で、でてきたのがこれ。こ
生成AIが人間の介在なしに自律的にソフトウェアテストを生成し実行、バグや脆弱性を発見してくれるAIテストエージェント「Spark」登場 ドイツに本社を置き、コード分析ツールなどを提供するCode Intelligence社は、起動すればあとは生成AIが人間の介在なしに自律的にソフトウェアテストを生成し実行することで、対象となるソフトウェアのバグや脆弱性などを発見してくれるAIテストエージェント「Spark」を発表しました。 An exciting milestone in software security testing: ???? ???????????? ???????? ?????, ??? ?? ???? ????? ???? ????? ???? ??????? ????? ???????????! Read the PR: https://t.co/wfuautln8i#AI
こんにちは、リテールアプリ共創部の戸田駿太です。 今回はChrome DevToolsを利用した手動テスト時の入力を効率化する方法をご紹介します。 この方法を使えば今まで手作業で行なっていた入力を簡易的に自動化することができるため手動テストの効率が向上します。 まずは実行動画から! 左のカード登録画面(仮)のバリデーションテストをしている様子です。 この動画で行なっていること 正常な値を入力して登録 正常登録の確認 正常な値の状態から1つの入力を編集してバリデーションエラーの状態で登録 エラーが発生することを確認 Recorderを使うメリット ✅ 手動テストの効率が向上する 今までテスト項目毎に入力していた値をミスなく入力できるようになります。 コードベースの確実な操作ができるのでテストのミスも少なくなるので安心感も増します。 ✅ Chromeの開発者ツールであるため、環境構築が必要ない
プロジェクト全体のテストを組み立てる際に重要な課題になるのが、テストレベル設計です。テストレベル設計は、ユニットテスト、結合テスト、システムテストといったテストレベルを、どのような責務・段取りで行うか分析・設計する活動です。 このテストレベル設計ですが、ここ10年程度の間に望ましいアプローチが変わってきたと感じています。今回はこの変化と、変化後のモダンなテストレベル設計の原則について、考えていることを書き出したいと思います。 旧来のテストレベル設計のアプローチ 旧来、このテストレベル設計では、Vモデルをベースしたアプローチや、自工程完結・品質積み上げをベースとしたアプローチがよく見られました。 このうち一つ目のVモデルをベースとしたアプローチは、要求定義から設計までの上流工程への対応を観点に、テストレベルを設計するものです。 (Vモデルが必須と明言しているわけではなく、極端な例ですが)例え
概要 playwright-mcpとCursorを活用し、E2Eテストをゼロから自動生成してみました。 本記事ではその検証プロセスと得られた知見を紹介します。 この記事で分かること Playwright MCPでE2Eテストを自動生成する方法 Playwright MCPの活用のヒント はじめに 昨今のMCPブームは収まることを知らず、日々新しいMCP Serverが公開されています。 そんな中、自動化テストツールとして有名なPlaywrightのMCP Serverが公開されました。 Playwrightには、既にユーザーがブラウザを操作しテストを生成できる非常に便利な機能がありますが、今回はそれを超えるために、ユーザーの代わりにCursor(MCP Client)を使用し、ブラウザの自動操作とE2Eテストの自動生成を行えるのかを検証しました。 検証環境 Cursor: claude-s
マイクロソフトは、Webアプリケーションのテスト自動化ライブラリ「Playwright」を用いた、Microsoft Azure上のテスト自動化サービス「Microsoft Playwright Testing」のプレビュー公開を発表しました。 Microsoft Playwright Testingに使われている「Playwright」は、マイクロソフトが中心となってオープンソースで開発しているWebアプリケーション向けテスト自動化ライブラリです。対応環境が幅広く柔軟で、精度の高いテストを特長としています。 具体的には、Chrome、Edge、Firefox、Safariの主要なWebブラウザのすべてを対象にしたテスト自動化が可能で、ヘッドレス、ヘッドありのいずれにも対応。モバイルエミュレーションを用いたAndroid版Google ChromeとMobile Safariのテストも、実
生成AIを巡る状況は、わずか1年ほどで劇的に変化しました。Claude Codeなど実用的なコード生成エージェントが普及し、開発現場に大きなインパクトを与えつつあります。 とはいえ、「どのような場面で活用できるのか」「実際の開発で本当に役立つのか」といった疑問を抱えるチームも少なくありません。 そこで本稿では「生成AIによるコーディングとテスト駆動開発(TDD)」をメインテーマに、TDDの第一人者・和田卓人さん(@t_wada)と、アジャイルコーチのやっとむさん、こと安井力さん(@yattom)が対談。TDDの意義や、チームでAIを活用するための現実的な視点を掘り下げます。 AIをどう導入し、どう使いこなすか──実践的なヒントが詰まった対談です。 2025年7月時点のコード生成エージェントの現場感 AIが広げるテスト導入の可能性 生成AIが自動テスト導入のハードルを下げた 「As-Is」の
テスト自動化フレームワーク「Playwright」にAIエージェント機能。自動的にテスト計画とテストコードの生成、テストコードのデバッグなど マイクロソフトが主導して開発しているオープンソースのテスト自動化フレームワーク「Playwright」の新バージョン「Playwright 1.56」がリリースされました。 Playwrightはデスクトップ向けのWebアプリケーションやモバイル向けのWebアプリケーションのテスト自動化が可能で、Chromium、WebKit、Firefoxなどの主要なモダンブラウザのエンジンのヘッドレス、ヘッドありのいずれの環境でも実行可能です。 OSはWindows、macOS、Linuxをサポートします。 テストはJavaScript、TypeScript、Java、Python、C#などで記述でき、ローカル環境での実行だけでなく、CI(継続的統合)環境での実
【更新】寄稿した記事が Web に公開されました 技術評論社様のご厚意により、 Software Design 2022年3月号に寄稿した「自動テストとテスト駆動開発、その全体像」が gihyo.jp にて公開されました。誠にありがとうございます! gihyo.jp はじめに 2022年2月18日発売の Software Design 2022年3月号 にて、第2特集「そろそろはじめるテスト駆動開発」の第1章「自動テストとテスト駆動開発、その全体像」を執筆いたしました。第1章では、混同されることの多い自動テスト関係の概念を自動テスト、テストファースト、テスト駆動開発(TDD: Test-Driven Development)の3つの段階に分け、それぞれの効果や注意点を包括的に整理整頓しています。 ソフトウェアデザイン 2022年3月号 作者:大竹 章裕,瀬戸口 聡,庄司 勝哉,光成 滋生,
アジャイル型の開発が導入されていない現場であっても、そして一人であっても、実践可能なアジャイルに関するプラクティスは存在します。 例えば、自動テストや、テストファースト、テスト駆動開発(TDD:Test Driven Development)です。ユニットテストフレームワークを使ってテストコードを書いて開発しながらテストを実行する「自動テスト」、実装の前にそのテストコードを書く「テストファースト」、テストと実装を繰り返しながらインクリメンタルに設計・開発を行うのが「TDD」。これらプラクティスのなかで、はじめの一歩となるのが自動テストですが、1人で実践するには、どこからはじめるか、どうテストを組み立てればよいのか、あるいは自分のテスト方法は適切なのか、不安を持つこともあるでしょう。 そこで本稿では、さまざまなチームや組織へのテスト手法の導入を支援し、精力的に講演や執筆などを行ってきたこの分
マイクロソフト、Webアプリテストの自動化サービス「Microsoft Playwright Testing」プレビューを開始 マイクロソフトは、Webアプリケーションのテスト自動化フレームワーク「Playwright」を用いた、Microsoft Azure上のテスト自動化サービス「Microsoft Playwright Testing」のプライベートプレビューを開始すると発表しました。 テスト自動化フレームワーク「Playwright」 Playwrightは、マイクロソフトが中心となって開発しているオープンソースのWebアプリケーション向けテスト自動化フレームワークです。 実行環境、対象ブラウザ、対応言語が幅広く、テスト実行時にはWebブラウザの動作を自動的に待つ機能を備えるなど、柔軟で精度の高いテスト自動化が実現できる点を特長としています。 具体的には、デスクトップ向けのWebア
Janet GregoryとLisa Crispinによる2019年9月発行の書籍『Agile Testing Condensed』の日本語翻訳版です。アジャイルにおいてどのような考えでテストを行うべきなのか簡潔に書かれています! Janet氏とLisa氏といえばAgile Testing DaysのYouTubeチャネルでも頻繁に登場しAgile Testingについてわかりやすい解説をしてくださってる 本書は訳者まえがきにあるが、著者たちの3冊の本(『Agile Testing: A Practical Guide for Testers and Agile Teams』、『More Agile Testing: Learning Journeys for the Whole Team』そして『Agile Testing Condensed: A Brief Introduction』
ナレッジワークでは、お客様に安定したサービスを提供するため、E2Eテストを活用した品質保証に取り組んでいます。ただし、E2Eテストの開発・保守には多くの時間と労力が必要で、正直なところ手間だと感じる場面も少なくありません。本記事では、そうした課題を Playwright MCP を活用して解消した取り組みをご紹介します。 ※(注記) Playwright MCP は Playwright をAIエージェントなどから実行し、ブラウザ操作を行えるようにする MCP(Model Context Provider)です 課題 主に次の3点に課題がありました。 ロケーターの記述に手間がかかる テストケースの記述に手間がかかる テストのデバッグに時間がかかる それぞれ具体的に説明します。 ロケーターの記述に手間がかかる E2Eテストでは、ページ上で行いたい操作に必要なボタンやインプットなどのロケーター(セレク
TDD(テスト駆動開発)を体験しながら Go を学べる学習コンテンツ「Learn Go with Tests」を紹介する❗️全てのコンテンツを実施してみて,非常に良かったのでまとめることにした💡 Go に入門できる TDD のサイクル (Red / Green / Refactor) を体験できる コンテンツは "35種類" もある 無料で学べる GitBook (GitHub) に公開されている 日本語対応 英語版 📚 quii.gitbook.io 日本語版 📚 andmorefine.gitbook.io コンテンツ一覧 なんと「35種類」もコンテンツがある❗️ Go fundamentals 🚢 21種類 Install Go(Go をインストールする) Hello, world(Hello, World) Integers(整数) Iteration(反復、繰り返し) A
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 12月10日の2022ソフトウェアテストアドベントカレンダーです。 Launchable社でエンジニアとして働いているcvuskと申します。機械学習界隈では機械学習を実用化するためのシステム開発の本を書いてたります。もし良かったら読んでみてください。 『機械学習システムデザインパターン』 『機械学習システム構築実践ガイド』 本ブログでは機械学習を用いてテスト実行を効率化する手法として、Predictive Test Selectionについて説明します。テスト実行時間やコストで課題を抱えているエンジニアに役に立つと幸いです。 昨今の開発
品質やテストといった活動が「本質的にアジャイルになって変わらなければならない」といった問題を定義し、その解決手段を提案する「今、全エンジニアに求められる『アジャイル開発での品質視点の変化』」。ここで株式会社デジタルハーツホールディングスの高橋氏が登壇。最後に、あらためて参加者からの質問に回答します。前回はこちらから。 どうすればうまくリファクタリングができるか 高橋寿一氏(以下、高橋):じゃあここでもう1回Q&Aタイムを取ります。 高木陽平氏(以下、高木):ありがとうございます。今Q&Aにまだ質問が上がっていないみたいなので、ちょっと私から質問します。リファクタリングをしなければいけないところって、逆に手をつけられないようなけっこう複雑怪奇な部分だと思うんです。そこらへんはどうすればうまくリファクタリングができるんでしょうっていう(笑)。 高橋:まず、日本人がすごくリファクタリングが嫌いな
目次 目次 はじめに(本記事の見どころなど) テストについて話し合わなくてはならない テストの目的 「うまくいかないかもしれないものは何ですか?」 なぜテストをするのですか? この場合に限り...... テスト駆動開発 〜テストについて語る前に説明が必要です〜 テストについて話しましょう なぜすべてのテストを自動化しないの? テストカバレッジは有用な指標ですか? 「テストをシフトレフトする」とはどういう意味ですか? いつ、どこでテストすべきですか? 十分なテストとはどれくらいですか? おわりに はじめに(本記事の見どころなど) 今回は著者本人の許可をもらった上で、「テストについて話し合わなくてはならない」(原題は「We need to talk about testing」)を翻訳したので紹介します。 dannorth.net 本記事はDaniel Terhorst-North(Dan North
1. はじめに 開発プロセスにおける要件・設計のセキュリティレビューは、専門知識を要するため属人化しやすく、工数の増大が開発全体のボトルネックとなり得る課題です。 本稿では、私たちセキュリティチームがこの課題に対し、生成AIであるGeminiを活用してレビュープロセスを自動化し、工数を大幅に削減した技術的アプローチとその効果について報告します。 2. 対象読者 この記事は、特に以下のような課題を感じている方々に向けて書いています。 セキュリティレビューの工数増大や属人化に悩むセキュリティ担当者の方 セキュリティのシフトレフトを考えているエンジニアリングマネージャーの方 生成AIを活用した具体的な業務改善事例に興味があるすべての開発者の方 3. 現状のセキュリティ活動と課題 「1:10:100の法則」が示す通り、脆弱性の修正コストは開発の後工程になるほど増大します。故に、開発ライフサイクルの
この記事はソフトウェアテストのカレンダー | Advent Calendar 2022 - Qiitaの23日目です。 毎年のことながら「何を書こう・・・」と悩んでいてTwitterに助けを求めたところ、@teyamaguさんからネタをいただきました(ありがとうございます) 最も役に立った、だとなかなか決めかねる部分があり、「読んでよかった本」をつらつらと書いていこうかと思います。 私が2022年に読んだというだけで、今年発売された本には限らない点ご注意ください。また、熟読した本ばかりではなく、ポイント読みやざっと流し読みした本も含めます。(意志薄弱 The BDD Books - Discovery (Japanese Edition) こちらは記事にも書きました。 『The BDD Books Discovery』はQAにも開発者にもPOにもPMにもとにかくみんなに薦めたい - テスト
プログラマ、テスト駆動開発者 和田卓人 学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒。執筆活動や講演、ハンズオンイベントなどを通じてテスト駆動開発を広めようと努力している。『プログラマが知るべき97のこと』(オライリージャパン、2010)監修。『SQLアンチパターン』(オライリージャパン、2013)監訳。『テスト駆動開発』(オーム社、2017)翻訳。『事業をエンジニアリングする技術者たち』(ラムダノート、2022)編者。テストライブラリ power-assert-js 作者。 日本におけるテスト駆動開発(以下、TDD)のエバンジェリストとして知られる和田卓人さん。TDDが世に出て20年あまりが経ち、開発者の間でその名が広がっています。その一方で、和田さんは「TDDの本来の意味を知らなかったり誤解したりしている人たちもかなり増えている」といいます。 今回は、TDDは本質
新規開発の設計支援や古いコードベースを甦らせて欲しいという相談をもらったときに、最初にちょろっとコードだけお手本的なコードを書いてから引き渡しているのだが、そのときに必ず結合テストを書くようにしている。 3, 4年前から僕と付き合いがある人からすると、 「「「あの sadnessOjisan がテストを書くだと!!!」」」 という感じだと思うのだが、最近はテストに思うところもあってちゃんと書いている。 そしてそのテストコードだが、基本的にはアプリケーションから分離して書いている。その話をしたい。 OGP OGP は野方ホープで海苔が分離されて出てきた時の画像だ。 アプリケーションから分離したテストとはどういうことか 最終的にはテスト対象のサーバーを Docker コンテナで固めて、そのコンテナに対して HTTP リクエストを投げてその結果や DB の中身を検証するコンテナを docker
みなさん、こんにちは。ソリューションアーキテクトの馬渕です。AWS 入社前は SIer で性能試験・性能問題解決に特化した部署におり、さまざまな業種のお客様のシステムに対する支援を実施していました。 さて、みなさんは AWS ソリューションライブラリ をご存知でしょうか。AWS ソリューションライブラリは、世界中のユーザーが直面する一般的な問題の解決策を提供するものとなっています。AWS CloudFormation のテンプレートと導入手順が用意されているため、すぐにデプロイしてお客様の課題に対応できます。また、アーキテクチャ図やその説明、コスト試算なども用意されています。 私がご紹介したいのが、その中でも人気のソリューションの一つである 分散負荷テスト ソリューションです。このソリューションは、負荷テストに必要な負荷クライアントを必要なタイミングで必要量だけ立ち上げて負荷掛けを実行し、
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く