testに関するyuki_2021のブックマーク (272)
-
yuki_2021 2022/07/27
-
AWSの主要サービスをローカルでエミュレート、「LocalStack」が1.0に到達
LocalStackを利用することで実際のAWSにアクセスすることなくローカルの環境で開発やテストを行えるようになるため、迅速な開発サイクルの実現やAWSの利用コスト削減などが期待できます。 LocalStackはオープンソースですが、無料で使える「Community」版では基本的なAPI群が利用可能、月額28ドルからの有償となる「Pro」版では全てのAPIが利用可能。さらに上位の「Team」版と「Enterprise」版も用意されています。 AWSの主要サービスをエミュレート LocalStackでエミュレートできるAWSのサービスは、Amazon S3、SQS、SNS、DynamoDB、Route53、AWS Lambdaなどをはじめとする80以上の主要なサービスです。 AWS Command Line Interface（AWS CLI）、AWS Cloud Development
-
-
Flutterのテスト
単体テスト 一般的にはFlutterSDKを必要とせず、プレーンなDartのみで動くUIと切り離されたテストです。 APIの呼び出しなどの通信はモックしてテストを行います。 Widgetテスト FlutterのWidgetを仮想的に操作しながら行うテストです。Widget版の単体テストで、 あるWidgetが正しく動くかを保証するために行います。 統合テスト アプリ全体が意図した通りに動くことを確認するためのテストです。コマンドラインで完結する他のテストと違い 実際にエミュレーターなどでアプリを立ち上げて行います。 あらかじめ定義しておいたテストスクリプトに合わせて、 仮想的に任意のWidgetをクリックしたり表示されている文字列をテストしたりすることで、より網羅的で統合的な テストを行うことができます。 人の手で行うデバッグをできるだけ自動化しようとするものです。 どのテストをどれだけ行
-
なぜLINEは600以上のテストケースをKotlinで書くのか？ “とにかく便利なテスト”を実現する、kotestのお役立ち機能
LINEが定期的に開催する、Kotlinをテーマにした技術者向けのミートアップ「LINE Developer Meetup for Kotlin」。今回は「LINEにおけるServer Side Kotlinの導入事例と開発裏話」をテーマに開催します。ここで登壇したのは、「Messaging API」のサーバーサイドを開発している川田裕貴氏。システムの改善における取り組みについて発表しました。全2回。後半は、「Messaging API」のテスト環境について。前回はこちら。 End to EndでテストができるテストケースをKotlinで書いている 川田裕貴氏：前半はMessaging APIの話をしてきましたが、後半はちょっと話を変えます。Messaging APIの中ではテストをいろいろ動かしているのですが、テストケースも全部Kotlinで書いています。普通のユニットテストではなく、E
-
世界中のITエンジニアが悩まされている原因不明でテストが失敗する「フレイキーテスト」問題。対策の最新動向をJenkins作者の川口氏が解説（後編）。DevOps Days Tokyo 2022
世界中のITエンジニアが悩まされている原因不明でテストが失敗する「フレイキーテスト」問題。対策の最新動向をJenkins作者の川口氏が解説（後編）。DevOps Days Tokyo 2022 世界中のITエンジニアが悩まされている問題の1つに、テストが原因不明で失敗する、いわゆる「フレイキーテスト」があります。 フレイキーテストは、リトライすると成功することもあるし、失敗する原因を調べようとしてもなかなか分かりません。GoogleやFacebookやGitHub、Spotifyといった先進的な企業でさえもフレイキーテストには悩まされています。 このフレイキーテストにどう立ち向かうべきなのか、Jenkinsの作者として知られる川口耕介氏がその最新動向を伝えるセッション「Flaky test対策の最新動向」を、4月21日、22日の2日間行われたイベント「DevOps Days Tokyo 2
-
世界中のITエンジニアが悩まされている原因不明でテストが失敗する「フレイキーテスト」問題。対策の最新動向をJenkins作者の川口氏が解説（前編）。DevOps Days Tokyo 2022
世界中のITエンジニアが悩まされている原因不明でテストが失敗する「フレイキーテスト」問題。対策の最新動向をJenkins作者の川口氏が解説（前編）。DevOps Days Tokyo 2022 世界中のITエンジニアが悩まされている問題の1つに、テストが原因不明で失敗する、いわゆる「フレイキーテスト」があります。 フレイキーテストは、リトライすると成功することもあるし、失敗する原因を調べようとしてもなかなか分かりません。GoogleやFacebookやGitHub、Spotifyといった先進的な企業でさえもフレイキーテストには悩まされています。 このフレイキーテストにどう立ち向かうべきなのか、Jenkinsの作者として知られる川口耕介氏がその最新動向を伝えるセッション「Flaky test対策の最新動向」を、4月21日、22日の2日間行われたイベント「DevOps Days Tokyo 2
-
フロントエンドのテスト戦略について考える
こんにちは。株式会社スタメンでFANTSのフロントエンドを担当している@0906kokiです！ 今回の記事では、FANTS におけるフロントエンドのテスト戦略について書きたいと思います。 🙋🏻♂️ はじめに みなさんはフロントエンドのテストを書いていますでしょうか？ 私が所属しているチームでは、今まで全体的なテスト指針が明文化されていなかったので、機能によってテストが書かれたり書かれなかったり、テストを書くにしても個人によって書く粒度にバラツキがありました。 直近でフロントエンドを書く人が増えていく / プロダクトがスケールしていくにつれて、そうしたバラツキによって生まれるコミュニケーションコストが大きくなってきたり、システム的な安全性を継続的に担保していくことが難しくなっていくように感じました。そのため、今まで方針を定めていなかったテスト戦略を、これから事業やプロダクト、チームがス
-
自動化大好きエンジニアたちが語る、効率化・品質向上 Tips【26選】 - RAKUS Developers Blog | ラクス エンジニアブログ
こんにちは、技術広報のyayawowoです。 「自動化（オートメーション／Automation）」 今、この言葉を聞いて胸がときめいた方に必見です！ 当社主催イベントでも人気の高い 「自動化大好きエンジニアLT会」全5開催分の資料をまとめて紹介します！ イベント詳細はこちらをご確認ください！ ・自動化大好きエンジニアLT会 ・自動化大好きエンジニアLT会 - vol.2 ・自動化大好きエンジニアLT会 - vol.3 ・自動化大好きエンジニアLT会 - vol.4 ・自動化大好きエンジニアLT会 - vol.5 目次 目次 手動テストやインフラ構築は自動化しよう APIテスト品質を向上させる Datadog Synthetic Monitoring APIテスト自動化とテストピラミッド TestLinkにテスト結果を自動的に登録 Cypressでサクッと始めるE2Eテスト 自動テスト環境を
-
Chrome 97のDevToolsに新機能、Webブラウザ上の操作を記録、再実行、編集、保存。Puppeteerスクリプトへのエクスポートも
Chrome 97のDevToolsに新機能、Webブラウザ上の操作を記録、再実行、編集、保存。Puppeteerスクリプトへのエクスポートも Googleは、来年1月に登場予定のChrome 97で、DevToolsにWebブラウザ上での操作内容を記録し、再実行や編集、保存などを可能にする新機能を搭載することを明らかにしました。 Introducing the new Recorder panel You can now record, replay and measure user interactions with @ChromeDevTools. See it in action - ordering coffee. Learn more about this preview feature (available in Chrome Canary now): https://t.c
-
ソフトウェア設計を学びたい人々にまず教えるべきことはテスト技法ではないか - 余白
根本の問題意識 ソフトウェアの設計スキルはどのように獲得する（させる）ことが効果的であるのか ソフトウェアアーキテクチャの目的 そもそもソフトウェアアーキテクチャはどのような欲望を満たすための方法か ソフトウェアアーキテクチャの目的は、求められるシステムを構築・保守するための必要な人材を最小限に抑えること である。 (CLEAN ARCHITECTURE) 「求められるシステムを構築・保守するための必要な人材を最小限に抑えたい」 => 構築容易性 と 保守容易性 を確保したい 構築容易性 「構築しやすさ」とは？ ソフトウェアを構築するとはどういうことか ソフトウェアの2つの価値: 「振る舞い」と「構造」 振る舞い: 要件を満たすこと => いわゆる機能 構造: 振る舞いを簡単に変更できること => いわゆるアーキテクチャ 構築しやすさ=価値の生み出しやすさ 要件を満たしながら振る舞いを変更
-
Software Design連載 2021年9月号 「テストが無い」からの脱却 - MonotaRO Tech Blog
こんにちは、鈴木です。 「テストが無い」状態を脱却しました。 「いつの時代かよ！」と突っ込まれるかもしれませんが、モノタロウは創業から 20 年ほど EC をやっています。昨日書いたコードも、15 年前に書いたコードも、元気にビジネスを支えています。 本記事ではモノタロウの EC を支える API の話をします。「テストが無い」状態がスタートラインでした。そこから、CI を導入して、ローカル開発環境の整備して、テストコードを書いて、リリースマネジメントを導入しました。 目新しいことは書きません。長寿の大規模システムであっても、愚直に数年取り組むことで、「前進できる！」「変えられる！」という実例を書きます。 ※本記事の初出は、 Software Design2021年9月号「Pythonモダン化計画（第2回）」になります。第1回の記事は「Software Design連載 2021年8月号
-
「人類よ！これがテスト自動化の実践だ！立ち上げのプロ＆運用のプロから実践知を発見しよう！」に参加してきた - 天の月
mabl-japan.connpass.com 今日はこちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。 会の概要 会で印象的だったこと 必要最小限の所(絶対壊したくない所)から導入を始める 自動化するテストの優先度の付け方 テスト自動化の恩恵 テスト自動化の落とし穴 全体を通した感想 会の概要 以下、connpassのイベントページから引用です。 テスト自動化の話は今回が2回目ですが、今回はより実践的な話を聴くことができるということです！ mabl Japan コミュニティウェビナーでは、mablを導入・実践するユーザー企業さまによる経験、実践情報を共有していただいたり、ソフトウェア品質やテスト自動化のエキスパートをお招きしてその知見を発信していただいております。 今回のテーマは「テスト自動化の実践」です。ゲストはUbie増原さま、アペルザ佐々木さまです。 増原
-
開発者の仕事を増やさずにバグを減らす、かしこいテスト戦略とは？【デブサミ2021】
ロジギアジャパン CEO 高橋寿一氏 上流品質を担保するために必要な3つのこと 高橋氏は、講演の冒頭で次の図を紹介した。 「これは、ケイパー・ジョーズという有名な学者さんの図です。データ自体はちょっと古いけど、開発プロセスのカオスな状態を示すのにいいと思っています。皆さんが、よくご存じの通り、開発プロセスの各段階で発生したバグは、その段階のうちに始末する必要があります。でも残念ながら、どこの組織でも、要求仕様のバグが最後のテストフェーズで見つかります。最悪の場合、保守フェーズつまり市場で見つかって、カオスな状態になってしまいます」 各段階のバグは、その段階のうちに始末する必要があるが、要求仕様のバグが最後のテストフェーズで見つかってしまう そして、上流で品質を担保する重要性をいくつかの例を挙げて力説した。たとえば、上流テストを十分におこなってバグを検出したグループと、上流で十分にバグを検出
-
なぜ自動テストの導入は失敗するのか？ - プログラマーの脳みそ
開発室の雑談。営業側のマネージャが言うには 「今のプロジェクトで自動テストの導入を試みている話をしたら、XXXさんのところでも過去にいくつか導入を試みたけどもみんな上手くいかなかったって話になって」 なるほど？ まあ確かに自動テストはシステム開発にとって魅惑の技法ではあるものの、では導入がうまくいっているか？ というと普及率は低いと言わざるを得ない。私がお手伝いしたプロジェクトでは、元請け側から自動テストをやるお達しが来たわけだが、紆余曲折あって掛け声倒れのような状態になってしまった。 ビジネス書の煽りタイトルのような本件だが、古式ゆかしき受注生産の業務システム開発プロジェクトに自動テストを導入しようとして失敗する事例を聞いたので、僕なりに分析して見出した要素を挙げておこうと思う。 V字モデル ソフトウェア開発の手法としてV字モデルというものがある。 オーダーメイドでシステムを作るにあたっ
-
ブラウザ自動化ツール カオスマップ風 - STAC2018 LT
5. • JavaScript をページに流し込んでブラウザを操作する • 😃実行早め • 😃セットアップ簡単 • 😐マルチブラウザ対応はツールによりけり • Nightmare - https://github.com/segmentio/nightmare • Cypress - https://github.com/cypress-io/cypress • TestCafe - https://github.com/DevExpress/testcafe 6. • Chrome や Firefox の開発者ツールの API を 使ってブラウザを操作する • ☺️ セットアップがほぼ不要ですぐに使え る • ☺️ CI 環境で動かしやすい • 😐 多ブラウザ対応はできない • Puppeteer / Puppeteer for Firefox - https://github.
-
Python と Playwright でブラウザを自動操作させるコードを自動生成したよ - Qiita
Playwright が昨年１年間で大幅パワーアップしていたので、使い方を確認したときの記録のまとめです。 ブラウザを自動操作できるということは、簡単なスクレイピングやブラウザ側のテスト自動化が簡単にできるようになります。 特に、Python での解説がまだまだ少なかったので、自分の学習を含めてまとめました。 今回は入門編ということで全体像をつかみつつ使用方法の流れを確認していただければありがたいです。 Selenium や Puppeteer を使っている方も、一度試す価値ありと思っています。 選定した理由 ブラウザのテストを Python で自動化したかったんです。 私なりの要件がありまして、非常にわがままな要件でしたが余裕ですべてクリアしました。 Python で書けること。社内で Python を使える方が多いので。pytest と連携してくれるとなおうれしい。 Docker コン
-
質とスピード（2020秋100分拡大版） / Quality and Speed 2020 Autumn Edition
質とスピード（2020秋100分拡大版） 2020/11/20 @ JaSST'20 Kyushu
-
テスト、正常系から書くか異常系から書くか - hitode909の日記
今週は同僚と毎日長時間ペアプロしていた。 おもしろかったのが、同僚のテストの書き進め方で、一番複雑な正常系のテストをちゃんと書いてから、その複雑なテストをもとに、いろんな条件を削っていって異常系のテストを作っていく、というところ。 僕は逆で、入力が空なら何も起きない、とか、一番簡単な異常系のテストを書いて、そこだけ通るのを確認して、よしよし、と進めていって、メソッド本来の動きは最後に確認して終わる。 変な進め方だな〜(主観)と思って眺めていたけど、たしかに正常系のテストが通っていれば、あとはバリデーションまわりのチェックとか、例外となる場合のチェックをすれば終わりで、異常系のテストがすごい速さで書かれていておもしろかった。 …という話をしたら、チームメンバーたちは正常系のテストから書きはじめるという人が多くて、正しくことを確認してから、1個ずつ前提となる条件を外してみて試す、と聞いて、同値
-
テスト文化を定着させた話 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 自動テストがほとんど整備されていないRailsプロジェクト、かつテスト文化がなかったチームに、約1年ほどかけてテスト文化を根付かせたことについてお話したいと思います。 経緯 当プロジェクトは、当初はCIは整備されているものの、テストはわずかに書いてあるのみでメンテナンスされないまま放置されており、CI上でもテストが失敗していることを無視してリリースされてされていました。 ある時、大きめの不具合を起こしてしまい、再発防止を考える上でせっかくCIでテストが回るようになっているのであればということで、本格的にテストを書いていくことを
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
