.NetConfでの発表資料です。 https://connpass.com/event/145322/

1. .NetCore3でテスト自動化＋α

2. 自己紹介
・石川達也
・(株)Codeer 代表取締役
・Microsoft MVP
・ささいなことですが(ブログ)
・OSS
Friendly
Selenium拡張
LambdicSql
Visual Studio and Development Technologies
http://ishikawa-tatsuya.hatenablog.com/
https://github.com/Codeer-Software

3. Desktop → Desktop
.NetCore3へ移行

4. // おすすめ手法
仕様化テスト

5. ↑これを仕様とする
// 仕様化
入力 出力

6. (.NetCoreへの移行）
実装！

7. ↑前と同じ
// 移行完了！再テスト
入力 出力

8. // 自動化
↑Assertを書いておく
もしくはログファイル
に落としておいて比較
w.Name.EmulateChangeText(“abc”);
w.Age.EmulateChangeValue(32);
w.Entry.EmulateClick();
w.Result.Text.Is(“result”);

9. ちなみに昔
WinForms + ネイティブ
のアプリで
VC++のコンパイラのバージョンを変えるときに
この手法が大いに役に立ちました。
その時は、今後のことも考えて仕様面を中心に
グレイボックス的にテスト設計をしました。

10. システムテストで大きく
振る舞いレベルのテストを書くと
多くのロジックが動いてくれるので
こんな感じの変更では
経験的にはコスパが良いです。
入力 出力
VM
M

11. // どれくらい作ればいいの？
必要なだけ。
悲観的に考えるなら、System.Object
から実装が変わってるから
どこがバグってもおかしくない。
https://marketplace.visualstudio.com/items?itemName=ConnieYau.NETPortabilityAnalyzer
MSを信じるならば、
これが通れば問題ないと考えれる

12. ・カバレッジで判断
（システムテストでは難しい・・・。無理ではない）
・内部で使っているAPIで分類して、
重要な分類はとおるようにする
・画面の崩れも気になる場合は、
一応スクショもとることにして
最初だけは人が目で確認。
あくまでレイアウトの崩れのみチェック
・仕様面/リスク面から重要なポイントを抑える。
（少なくとも正常系ワンパスくらいは作っておきたい）
// どれくらい作ればいいの？

13. Windowsアプリを意のままに操作するためのライブラリ
弊社製品FriendlyはMicrosoft MVP Showcaseで2位になりました。
http://blogs.msdn.com/b/mvpawardprogram/archive/2014/11/04/mvp-showcase-winners.aspx
IPAの「先進的な設計・検証技術の適用事例報告書 2015年度版」に掲載。
http://www.ipa.go.jp/sec/reports/20151118.html
.NetCore対応！

14. Friendlyのデモ

15. おまけ。Friendlyの.NetCore対応話

16. CreateRemoteThread
でWin32のDLLをイン
ジェクション
HostAPIで
DotNetのDLL読み込み
要求を受け付けるサーバー起動
API実行要求を投げる

17. これがダメだと思ってた
・HostAPI
.Framework専用だからCoreには使えない
・DotNetのDLL読み込み
CoreからFrameworkのDLLは読み込めない
Standard化したものを作らないと・・・

18. いけた！
・HostAPI
Core用のHostAPIがあった！
（誰得のAPI？）
・DotNetのDLL読み込み
CoreからFrameworkのDLLは読み込めた！
？？？だったらStandardいらんじゃん・・・

19. Frameworkで
作った.dll
Frameworkのdll群Coreのdll群
Frmework.exeCore.exe
Exeの種類で参照先を変更している

20. dotnet publish

21. dotnet publish -r win-x64 /p:PublishTrimmed=true
dotnet publish
dotnet publish -r win-x64
dotnet/shared以下にあるdll以外の実行に必要なファイルが集められる
（ランタイムがインストールされてないと実行できない）
dotnet publish -r win-x64 /p:PublishSingleFile=true
win-x64環境で実行に必要なアセンブリの必要最小限が集められる
（ランタイムがインストールなくても動く）
※両方もちろん可能
win-x64環境で実行に必要なアセンブリが全部集められる
（ランタイムがインストールなくても動く）

22. /p:PublishTrimmed=true
え？

23. え？
/p:PublishTrimmed=true

24. /p:PublishTrimmed=true
やるなら自動テストは必須・・・

25. /p:PublishTrimmed=true
そこまでは頑張ってほしくなかったな・・・

26. デモ
それぞれをFriendlyで操作

27. dotnet publish のその他の使い道
参照先のdllがない！
.netcore, standardの
dllのプロジェクトは
地味な変更点として
Webアプリ、コンソールアプリは
2xまではdllだったけど
3からはexeになってる。
ビルドするとbinフォルダに参照先のdllも集められる

28. dotnet publish を dllのプロジェクトに対して使う
できた！これでこのフォルダのdllを読み込めば色々可能。

29. Web

30. // Selenium
作りたいのは、
プロダクトと自動テストの
協調処理
テストチーム
開発チーム

31. 価値のある自動テスト

32. // どうしても量が必要
質 量×

33. 製品紹介

34. Test Assistant Pro
Code と Tool のシナジー効果！
あなたのプロジェクトに Just Fit！
Driverの作成 + シナリオの作成の大部分をサポートします。
実装補助ツールという位置づけなので、
コードがわからない人だけで使うことはできません。
.NetCore対応！

35. 初期学習
難易度
カスタマイズ プロジェクト
ごとの調整
作成速度 ソース
可読性
メンテ効率 動作確実性 実行速度 テスト実行時
ライセンス
某社ツール 低 △ 不要 △ △ △ △ △ 必要
TesAssistantPro 高※1 ◎ 必要 ◎ ◎ ◎ ◎ ◎ 不要
“価値のある自動テスト”を作成/運用することが可能な
世界でも稀有なツールです！
※1 Friendlyの学習コストを入れています。

36. // アーキテクチャ

37. // Codeer 技術者大募集！
CodeにこだわりCodeで語る。