Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
Riverpodでテストを書こう
Search
tokku5552
May 11, 2022
Programming
370
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Riverpodでテストを書こう
2022/1/29 第一回FlutterGakkai登壇資料
tokku5552
May 11, 2022
More Decks by tokku5552
See All by tokku5552
他責思考で考える、EMとICの本音
tokku5552
1
200
Google CloudとAWSのコンテナ実行環境比較
tokku5552
0
270
高スループット・低レイテンシを実現する技術
tokku5552
3
17k
AWS CDKのススメ
tokku5552
1
580
Messaging APIのメッセージオブジェクトを検証できるChrome拡張機能を作った話
tokku5552
1
180
FlutterにLINEログインを仕込んで通知メッセージを送る
tokku5552
2
1.1k
AWS CDK × Reactでliffをつくる
tokku5552
1
610
Flutterで単体テストを行う方法とGitHub Actionsを使った自動化
tokku5552
1
160
ネットワーク基礎 - WEBページが表示されるまで
tokku5552
1
340
Other Decks in Programming
See All in Programming
Verilogで学ぶCPU自作入門.pdf
uyuki234
8
3.7k
更なる可用性を求めて、5年間運用したKotlinのアプリケーションをGoでリプレイスする話
ken_tunc
0
390
スマート反転とウェブアクセシビリティ
camiha
0
220
UPDATE をやめる — EF Core でマスタをバージョン管理する
panda728
PRO
0
910
選挙速報を多くのユーザーへ 届ける Live Activities 設計
hamayokokuririn
0
180
テストを司るデーモンに会いに行く 〜隔離した仮想マシンでテストを通すまで〜
h1d3mun3
1
590
FreeBSDでZabbixを動かす
kenkino
0
330
App Storeの外へ──日本のiOSサイドローディング入門 for iOSDC Japan 2026
yuukiw00w
0
270
仕様駆動開発による爆速プロダクト開発 / Bakusoku Spec Driven Development
kobakei
0
140
thread_parallel_with_free-threaded_Python_and_NumPy.pdf
riku_sakamoto
0
360
Agents on Rails - Rails at Scale 2026
irinanazarova
0
280
[ハンズオン]AIへの指示だけで「五目並べ」を作ってみよう
satoshi256kbyte
1
280
Featured
See All Featured
How Software Deployment tools have changed in the past 20 years
geshan
2
34k
Hiding What from Whom? A Critical Review of the History of Programming languages for Music
tomoyanonymous
3
1.3k
Raft: Consensus for Rubyists
vanstee
142
7.7k
State of Search Keynote: SEO is Dead Long Live SEO
ryanjones
0
290
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
254
22k
Building AI with AI
inesmontani
PRO
1
1.3k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
659
62k
What Being in a Rock Band Can Teach Us About Real World SEO
427marketing
0
1.1k
Game over? The fight for quality and originality in the time of robots
wayneb77
1
290
Believing is Seeing
oripsolob
1
230
How to make the Groovebox
asonas
2
2.5k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
141
35k
Transcript
Riverpodでテストを書こう FlutterGakkai 2022/1/29
目次 • Flutterでのテストことはじめ • サンプルプロジェクトの解説 • Unit Test • Widget
Test • まとめ 2
自己紹介 とっく(@tokkuu) • 都内AdTech企業のWebエンジニア • php/python/TypeScript • AWS周り 3-tierからサーバレスまで •
元々はSIerのインフラエンジニア • Flutter歴は1年半くらい 3
はじめに • 説明すること ◦ Riverpodでのユニットテストの書き方 ◦ RiverpodでのWidgetテストの書き方 • 説明しないこと ◦
DIを用いたProviderでのテストの書き方 ◦ Integration Testについて ◦ CIへの組み込みやDDDについて • Providerでのテストについて ◦ Flutterで単体テストを行う方法とGitHub Actionsを使った自動化 • DDDの説明(同じサンプルを使用) ◦ hooks_riverpod + state_notifier + freezedでのドメイン駆動設計 4
Flutterでのテストことはじめ
Flutterにおけるテストの種類 Flutterには3種類のテストがある 公式ページ:https://flutter.dev/docs/cookbook/testing ・Unit Test ・Widget Test ・Integration Test いわゆる単体テスト。関数、メソッド、クラスの検証を行う
Widgetが正しく生成されるかのテスト。 結合テスト。シナリオを書いてエミュレータ上で自動操作によるテス トが行える。 6
Unit Testの準備 ・パッケージの導入 pubspec.yamlにflutter_testが追加されていること 7
Unitテストの書き方と実行方法 プロジェクトルートの testフォルダの下に XXX_test.dartファイルを作成 import 'package:flutter_test/flutter_test.dart' ; import 'package:todo_app_sample_flutter/data/todo_item.dart' ;
void main() { group('TodoItemのゲッターのテスト ', () { final TodoItem todoItem = TodoItem( id: 0, title: 'title', body: 'body', createdAt: DateTime (2020, 1, 1), updatedAt: DateTime (2020, 1, 1), isDone: true, ); test('idのテスト', () { expect (todoItem.getId, 0); }); 8
Unitテストの書き方と実行方法 プロジェクトルートの testフォルダの下に XXX_test.dartファイルを作成 import 'package:flutter_test/flutter_test.dart' ; import 'package:todo_app_sample_flutter/data/todo_item.dart' ;
void main() { group('TodoItemのゲッターのテスト ', () { final TodoItem todoItem = TodoItem( id: 0, title: 'title', body: 'body', createdAt: DateTime (2020, 1, 1), updatedAt: DateTime (2020, 1, 1), isDone: true, ); test('idのテスト', () { expect (todoItem.getId, 0); }); main関数の中に 実際のテストを記載 test(‘テストケース名’,(){ 実際のテスト処理 expect(結果,期待する値); }); group()でテストケースを まとめることが出来る。 9
テスト実行 1. テストファイルを右クリック 2. Run ‘test in <テストファイル>’ デバッグの画面が開いて 結果が表示される
10
サンプルプロジェクトの解説
サンプルプロジェクトの説明 • DDDぽく書いている • application層の todo_app_service.dartがdomain層の classを使う形 • ビジネスロジックのテストという文脈で は、todo_app_service.dartを
テストすれば十分 • このプロジェクト自体の解説は Qiitaの記事参照 • 全体のコードはこちら 12
サンプルプロジェクトの説明 - TodoAppService • todo_app_serviceは todoListRepositoryに依存して いる • todoListRepositoryはFirebase との通信を担う
• DDDじゃない場合、MVVM + Repositoryのパターンなどで は、View Modelでテストすれば 良い 13
テストの準備 - TodoListRepositoryのモックを作る • TodoListRepositoryを実装した TodoListRepositoryMemを作 る • TodoListRepositoryMemでは Firebaseとの通信を行わず、テ
スト用に一時的にデータを貯め れるように実装しておく • コード 14
テストの準備 - ProviderContainerでoverrideする • Riverpodでは ProviderContainerを使ってモッ ク用のクラスを宣言することで、 Providerを上書きできる。 • 右のように
TodoListRepositoryMemを 宣言しておくことで このコンテナから呼び出したリ ポジトリやサービスでは 上書きされたモック用クラスが 呼び出される様になる。 15
Unit Test
Unit Test - 宣言 • Widgetの生成が絡まない ロジックをテストする • setUpやtearDownが使える ので、先程のコンテナの宣言や
データのセットが行える。 • Null Safetyなバージョンの Flutterであれば、コンテナや モックはlateで宣言しておくこと でnon-nullableに扱える 17
Unit Test - 実行 1. 空のTodoItemを_repositoryに セットし、自動生成され 割り当てられたnextIdを取得 2. テスト対象のクラスを
インスタンス化 3. テスト対象のメソッドを 実行し結果を expectメソッドで比較 2. 3. 1. 18
Widget Test
WidgetTest - 宣言 • モック用クラスは引き続き containerから取得 • Widgetを生成するために、 tester.pumpWidgetの中で ProviderScopeを宣言し、モック
にoverride • childの中でテスト対象Widget の描画に必要なWidget、 MaterialAppなどを宣言した上 で対象のWidgetを宣言 20
WidgetTest - 実行 • find.textで描画されたWidgetの 中のテキストを探す。 findsOneWidgetは「それが1つ あること」という意味になる。 • tester.tapなどで、特定のIcon
などを探してボタンをタップさせ ることもできる。 21
まとめ • Riverpodで記述するときは、Repositoryをあとからoverrideできるため、わざわざ 抽象クラスを作っておいて、DIできるようにドメインクラスを実装する必要がない • Unit Testのほうが比較的簡単に、最低限のロジックのテストが書きやすい • CI組んでおけば、快適にTDDできそう •
Widget Testまで書いて、Codecovなどを使ってカバレッジを可視化して、CI組んで Slack通知まで設定しておくと快適に、より安全に開発が進められると思いました。 (関連記事) ご清聴ありがとうございました