アカウント作成時のメール認証リンクをMailSlurp + Pythonで踏んでみた - Qiita
はじめに テストでアカウントを大量に作る必要があったので、操作の自動化しようと思ったのですがメール認証が！ むむむ... どうしよう...と思っていたところ、 MailSlurp なるものがあることを教えてもらいました。 よし！挑戦してみよう！ 利用環境 macOS Big Sur 11.1 Python 3.8.6 手順 準備 MailSlurp公式サイト でアカウントを作成します アカウントを作成すると API Key が発行されるのでメモしておきます MailSlurp公式サイト に再ログインする場合は、 ログイン画面 で登録したメールアドレスを入力します。 するとメールにアクセス用のリンクボタンが送られてくるので、そこからアクセスします。 curl まず試しにcurlで叩いてみます。 メール Inbox の作成
Mailtrap を使って受信メール確認を自動テストに組み込む - kakakakakku blog
メール配信プラットフォーム「Mailtrap」を使うと，開発中にメールをテストしたり，実際にメールを配信したり，メール関連の悩みを幅広く解決できる❗️ちょうどメール関連のテスト戦略を設計していて，気になっていた Mailtrap の Email Testing を試してみた✌️ mailtrap.io Mailtrap を本格的に使うなら Business Plan 以上にすると良さそう．1ヶ月に 50,000 件もメールを受信できるし，テストに使える専用メールアドレスも割り当てられる．しかし Free Plan でも1ヶ月に 100 件はメールを受信できるし（Inbox に残せるのは 50 件まで），Mailtrap API も使えるし，検証目的なら十分そう👌 mailtrap.io ＼( 'ω')／ Mailtrap ならメールテストを自動テストにも組み込めるぞ〜 Project と
TDDを実践する中で身につけてた「設計に関するスキル」を3つ - Mitsuyuki.Shiiba
TDDを実践する中で身につけた「設計に関するスキル」があるなぁと思ったのでメモを残しておくことにする。TDDをやるときのスキルではなく設計をするときのスキル。 染み込んでいる TDDは以前に書いたように（ってもう7年も前か・・・）あんまり使わなくなっている。でも心の中にある。ウェブアプリケーションエンジニアとしての自分にとても大きな影響を与えている。 bufferings.hatenablog.com TDDから学んだ設計に関するスキル 3つ思い浮かんだ まずは動くものを作る 必要な分だけ作る 「ありえない」の処理を考える 注意 ウェブアプリケーションを書くときのことを考えながら書いている。ライブラリやフレームワークのようないろんなユーザーから利用されるものは、今回の話の対象ではない。 1. まずは動くものを作る TDDで実装を書くときは「キレイじゃなくてもいいからテストがグリーンになる（
QAエンジニアがいない会社に入社してやったこと、まだやれてないこと - TalentX Tech Blog
はじめまして。2023年2月に入社したQAエンジニアの大出です。 前職はフリマアプリを開発する会社で約8年QAエンジニアとして働いていて、TalentXで初めてtoBのサービスのQA業務を行うことになりました。 入社前の状況 やったこと 新規開発の検証 テストプロセス改善 テスト計画の作成 ドキュメントの整理 バグチケットの整理 ドッグフーディング 採用 まだやれてないこと 終わりに TalentXは2015年にMyReferというサービスをリリースして以来、2023年2月に自分が入社するまで社内にソフトウェアテストを専門に行うメンバーは在籍しておらず、開発エンジニアが自分達で全てテストを行っていました。 そういう状況で私が入社してから約1年間でやってきたことを振り返りたいと思います。 TalentXの開発に興味がある人や、ソフトウェアテストを専門に行うメンバーが居ない会社でこれからQAエ
Playwrightを使ったE2Eテストを導入した話 - Uzabase for Engineers
はじめに こんにちは。ソーシャル経済メディア「NewsPicks」の QA/SET チームの海老澤です。 先日 弊社で E2E テスト実行するために Playwright を導入したため紹介させてください。 E2Eテストとは E2Eテスト（エンドツーエンドテスト）とは、ソフトウェア開発におけるテスト手法の一つで、アプリケーションが実際の運用環境と同様の条件下で正しく動作することを確認するためのテストです。 システムの開始点から終了点までを通じて、ユーザーの視点でアプリケーションのフローを追い、機能全体が連携して期待通りに動くかを検証します。具体的には、ユーザーが行うであろう一連の操作をシミュレートして、データがシステムを通じて適切に流れるかや、最終的なアウトプットが正しいかどうかを確認します。E2Eテストにより、部分的な単体テストや統合テストでは見逃されがちな問題を発見することができます。
Codemagic でモバイルアプリの CI/CD を始めましょう (updated 2021) - Qiita
Codemagic は、今年の２月に発表された Flutter UX 調査チームによる Q4 2019 の調査結果において、開発者が CI/CD で採用しているサービスのトップ３に挙げられており、（Codemagic、 Github Actions、 GitLab）、その中でも満足度が最も高かったことが示されています。 Codemagic は、Google と提携して Flutter 専門の CI/CD サービスとして開始されただけあって、Flutter を手厚くサポートしています。また、以下の翻訳で示されているように、Flutter に加えて Android ネイティブ、 iOS ネイティブ、React Native のサポートが追加されましたので、既存のそれらのアプリの資産がある場合でも、Codomagic をすべてのアプリに対応する統一した選択肢として検討できるようになりました。 ま
TestをGitHub ActionsからXcodeCloudに移行した話
この記事はLuup Advent Calendarの13日目の記事です。 こんにちは、iOSエンジニアの大瀧です。 今回はGitHub Actionsで行っていたTestの実行をXcodeCloudに移行した話を書いていきます。 XcodeCloudの概要 XcodeCloudはXcodeやAppStoreConnectからGUIでワークフローを設定、証明書の管理やTestFlightへの自動アップロード等、Appleプラットフォームに最適化されたCI/CDサービスです。 料金 GitHub ActionsやBitriseに比べるとかなりお得になっています。 GitHub ActionsではTestの実行に1ビルドで40〜50分ほどかかっていて1ビルドにつき$4($0.08×50m)もかかっていてました。さらに常時4人ほどのエンジニアがコードを書いていたので月$700ほどの費用がかかってい
Android アプリの起動チェックを行う GitHub Actions ワークフロー
ネタです。 GitHub Actions の runner 上のエミュレーターで、アプリが正常に起動できるかのみをチェックするワークフローです。Renovate や Dependabot のようなボットが作成するプルリクで動かすと、少なくとも起動できるところまではこのワークフローで担保できるのでよいかも。 普通に Espresso 等で起動を確認するテストコードを用意してもよいのですがネタなのでw name: Launch Check on: pull_request jobs: check: runs-on: macos-latest steps: - name: Check out uses: actions/checkout@v4 - name: Set up JDK uses: actions/setup-java@v3 with: distribution: 'zulu' jav
UPSIDERのこれからを担うFlutterアプリのアーキテクチャ - UPSIDER Techblog
こんにちは、UPSIDERで日々モバイルアプリ開発をしているふっくです。 UPSIDERでは今後、よりアプリ開発に注力し決済プラットフォームの中核的な役割を果たすことを目指しています。 今回は、今後の開発・運用を目指して考えたFlutterアプリ向けのアーキテクチャを紹介します。 ネイティブアプリの世界で触れてきた色々なアーキテクチャ・フレームワークを参考に、開発の後半でも順調にスケールさせることができるように、工夫を凝らしました。 本アーキテクチャで作ったサンプルアプリもあるので、ぜひ以下のリンクから見てみてください。 https://github.com/upsidr/flutter_architecture_blueprint デモはこちら https://upsidr.github.io/flutter_architecture_blueprint/ 対象読者 目指すところ 参考に
Flutterの自動テストをGithub Actionsで実行する - 千里霧中
Flutterのユニットテスト、ウィジェットテスト、インテグレーションテスト(エミュレータを使ったテスト)をGithub Actionsで実行する方法についてです。 対象のディレクトリ構成 (rootディレクトリ) test ユニットテスト、ウィジェットテストのテストコード test_driver app.dart インテグレーションテストのテストコード .github workflows flutter_test.yaml flutter_integration_test.yaml 他Flutterアプリのプロジェクトファイル ユニットテスト、ウィジェットテストのワークフロー 上記ディレクトリファイルにて、testディレクトリのユニットテスト、ウィジェットテストをGithub Actionsで実行する場合、次のようなワークフロー定義ファイルflutter_test.yamlを作成します。
【Flutter】Integration Testを極めるためのテクニック集 - Qiita
testコマンドで実行するとビルド→実行→終了→ビルド→実行→終了のように、動作確認で実行するたびに毎回ビルドが発生するので待ち時間が発生します。 実装完了したテストを実行するときはこれで良いのですが、実装中は効率が悪いです。 flutter runコマンドを使うとshift+rでホットリスタートが使えるので爆速で実行できます。 2. 非同期処理用の描画待ち関数を用意する 標準で描画待ち用の関数 ( tester.pumpAndSettle() )がありますが、万能ではありません。この関数は指定された秒数（デフォルは100ミリ秒）ごとに画面を確認し、描画待ちのものがなくなるまで待つという動作をします。 通常の画面描画であれば良いのですが、DBからのデータ取得や複雑な処理など時間がかかる非同期処理によって画面が更新された場合に対応できません。 DBからの取得は毎回必ず早いとは限らないので、t
Ruby: テストを不安定にする5つの残念な書き方（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 元記事: Five ways to write a flaky test 原文公開日: 2016/10/21 著者: Kir Shatrov（@kirshatrov） 2017/05/08: 初版公開 2023/03/01: 更新 不安定なテストは、日々の苦労を台無しにしてくれる技術上の負債の一部となります。テストが不安定だとCIが赤信号になってしまい、それだけのために新しいコードのリリースを中断してビルドをやりなおすはめになります。実際のコードはどこもおかしくないのに、どこかがおかしいのではないかという疑念が湧くと、ストレスの元になります。 数百人の開発者と5万件のテスト項目があるような大規模案件1では、不安定なテストが混入する可能性がさらに高まります。 本記事で扱うデモの中には、テストの実行順序に関連するものもありますが、そうでないものも
テスト自動化関連ツール・ライブラリまとめ - Qiita
分類については独断です。また、こつこつ「ひとこと説明」を追加していく予定です。 Selenium関連については Awesome Selenium : 素晴しい Selenium ライブラリの数々 - Qiita が参考になります。 FAQ なんで＊＊＊を除いているのか 恣意的に除いていることはないので、編集リクエストかコメントをください GUIテスト自動化ツール モバイル・デスクトップアプリ・ブラウザのうち複数の対象のGUIを操作できるテスト自動化ツール。 有料 インストール型 UFT One QTP(Quick Test Professional)→UFT(Unified Functional Testing)→UFT One Silk Test UFT Oneと同じくMicroFocus製で、UFT Oneのほうがメジャーな印象（筆者主観） Ranorex TestComplete W
たった２つのステップを意識するだけで書けない単体テストがほぼなくなる - Qiita
はじめに この記事は レガシーコード改善ガイド: 保守開発のためのリファクタリング を参考に手を動かしてみて、ある程度自分の中で体系的にまとまった知識のアウトプットです。 この記事で扱う内容 この記事で扱うのは主にレガシーコードで単体テストを書く際のハードルになりがちな 依存関係の排除 に関する手法を紹介します。 この記事を読んだ後に、 『この観点を持っておけば単体テストをスムーズに書いていけそう！』 『今までモック使ってたけど意外とモック使わなくても書けるね！』 となったらいいな、と思います。 ちなみに、今まであんまりテスト書いたことないよーて人は以下の記事など参考にして一度やってみてください。 前提の話： この記事の本旨は「テスト書きにくいプロダクトコードも依存関係を排除すれば楽にテスト書けるよ」なので、それ設計的にアウトでは？リファクタリング耐性低くない？みたいな話は度外視してます。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Disposable email accounts and unlimited email addresses
Mailtrap：メール配信プラットフォーム
Flutter automated screenshot testing using the integration_test package | Codemagic Blog
BuildJet for GitHub Actions
Android Emulator Runner - GitHub Marketplace
我々はなぜテストをするのか？
