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 をすべてのアプリに対応する統一した選択肢として検討できるようになりました。 ま
【Flutter】Integration Testを極めるためのテクニック集 - Qiita
testコマンドで実行するとビルド→実行→終了→ビルド→実行→終了のように、動作確認で実行するたびに毎回ビルドが発生するので待ち時間が発生します。 実装完了したテストを実行するときはこれで良いのですが、実装中は効率が悪いです。 flutter runコマンドを使うとshift+rでホットリスタートが使えるので爆速で実行できます。 2. 非同期処理用の描画待ち関数を用意する 標準で描画待ち用の関数 ( tester.pumpAndSettle() )がありますが、万能ではありません。この関数は指定された秒数（デフォルは100ミリ秒）ごとに画面を確認し、描画待ちのものがなくなるまで待つという動作をします。 通常の画面描画であれば良いのですが、DBからのデータ取得や複雑な処理など時間がかかる非同期処理によって画面が更新された場合に対応できません。 DBからの取得は毎回必ず早いとは限らないので、t
テスト自動化関連ツール・ライブラリまとめ - 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
はじめに この記事は レガシーコード改善ガイド: 保守開発のためのリファクタリング を参考に手を動かしてみて、ある程度自分の中で体系的にまとまった知識のアウトプットです。 この記事で扱う内容 この記事で扱うのは主にレガシーコードで単体テストを書く際のハードルになりがちな 依存関係の排除 に関する手法を紹介します。 この記事を読んだ後に、 『この観点を持っておけば単体テストをスムーズに書いていけそう！』 『今までモック使ってたけど意外とモック使わなくても書けるね！』 となったらいいな、と思います。 ちなみに、今まであんまりテスト書いたことないよーて人は以下の記事など参考にして一度やってみてください。 前提の話： この記事の本旨は「テスト書きにくいプロダクトコードも依存関係を排除すれば楽にテスト書けるよ」なので、それ設計的にアウトでは？リファクタリング耐性低くない？みたいな話は度外視してます。
FlutterのWidgetテストが終わらない現象の対応 - Qiita
背景 FlutterでFirebaseを組み込んだアプリのWidgetテストを行おうとすると、一向にテストが終わらない現象が発生したので備忘録として残します。 結論として、Firebase.initializeApp()がプラットフォーム上でないと動作しないために発生している事象のようなので、Mockを用意してあげることで解決しました。 コード testWidgetの中でFirebaseを初期化しようとしています。これがないとWidgetテスト実行時に No Firebase App '[DEFAULT]' has been created - call Firebase.initializeApp() と怒られていたために記述していました。 void main() { testWidgets('Counter increments smoke test', (WidgetTester t
Flutterでの単体テスト（完全版） - Qiita
以上です。 暗黙的インターフェイス DartではJavaの文法でのinterface はありません。代わりにabstract クラスで代用することになりますが、わざわざテストのためにabstract クラスを ___作る必要はない___です。 DartではImplicit interface(暗黙的インターフェイス)が言語レベルで組み込まれています。 つまり、全てのクラスに対して、implements するとそのインターフェイスを実装することになります。 class Person { final _name; Person(this._name); // publicなこのメソッドがinterface String greet(String who) => 'Hello, $who. I am $_name.'; } class Impostor implements Person { ・
FlutterのWidgetTestで待ち(疑似スリープ)を入れる - Qiita
環境 訳あって最新版を使っていません(macをCatalinaにアップデートできない==Xcodeの最新版を入れられないので)。 従って、バージョン違いによる不動作などあるかも知れません。お気づきの点があったら是非コメント下さい。 ※本稿は特に、Flutterテストパッケージの今後のアップデートにおいて、動作・仕様が変わる可能性があります。 $ flutter --version Flutter 1.12.13+hotfix.5 • channel stable • https://github.com/flutter/flutter.git Framework • revision 27321ebbad (4 months ago) • 2019-12-10 18:15:01 -0800 Engine • revision 2994f7e1e6 Tools • Dart 2.7.0
Python と Playwright でブラウザを自動操作させるコードを自動生成したよ - Qiita
Playwright が昨年１年間で大幅パワーアップしていたので、使い方を確認したときの記録のまとめです。 ブラウザを自動操作できるということは、簡単なスクレイピングやブラウザ側のテスト自動化が簡単にできるようになります。 特に、Python での解説がまだまだ少なかったので、自分の学習を含めてまとめました。 今回は入門編ということで全体像をつかみつつ使用方法の流れを確認していただければありがたいです。 Selenium や Puppeteer を使っている方も、一度試す価値ありと思っています。 選定した理由 ブラウザのテストを Python で自動化したかったんです。 私なりの要件がありまして、非常にわがままな要件でしたが余裕ですべてクリアしました。 Python で書けること。社内で Python を使える方が多いので。pytest と連携してくれるとなおうれしい。 Docker コン
テスト文化を定着させた話 - Qiita
はじめに 自動テストがほとんど整備されていないRailsプロジェクト、かつテスト文化がなかったチームに、約1年ほどかけてテスト文化を根付かせたことについてお話したいと思います。 経緯 当プロジェクトは、当初はCIは整備されているものの、テストはわずかに書いてあるのみでメンテナンスされないまま放置されており、CI上でもテストが失敗していることを無視してリリースされてされていました。 ある時、大きめの不具合を起こしてしまい、再発防止を考える上でせっかくCIでテストが回るようになっているのであればということで、本格的にテストを書いていくことをチームで合意しました。 当初の方針 とはいえ、「テスト文化」自体がチームにほぼ根付いていない状態だったので、最初からカバレッジを「~~%にする」等の目標は立てませんでした。 また、テストが書かれていないコードにテストを追加していくことはとても骨が折れる作業で
TDDという名の幻想... - Qiita
TDDは死んだ。テスティングよ栄えよ。 by DHH http://d.hatena.ne.jp/yach/20140424#p1 【翻訳】TDD is Fun http://diskogs.hatenablog.com/entry/2014/04/25/085112 を読んで思ったことをつらつらと書いてみます。 TDDはできれば、やったほうが良いのは確か？です。 しかし、実際の開発現場で全面的に採用するのは ミドルウェア等の画面の存在しないソフトの開発以外では ほとんどの場合、無益です。 なぜなら、TDDを採用すると開発時間が膨らむ、すなわち、開発コストが 膨らむからです。そして、ソフト開発では細かな仕様は変化していきます、 するとTDDではそれに合わせ、テストを修正していかなくてはなりません。 また、TDDで書かれたテストが全てのケースを抜けなく網羅できていること は稀です、抜けは必ず
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Flutterのテストについて調べた - Qiita