DeNA Testing Blog

Make Testing Fun, Smart, and Delighting End-Users

フロー解析を実装した静的解析ツールをOSS公開しました

こんにちは、SWETの秦野です。

2024/8/22のCEDEC2024にてIKさんと私でRoslynアナライザーに関する発表を行いました。 そして先日、本発表で紹介した静的解析ツールをOSSとして公開しました。

本記事では、CEDECの発表内容と公開したツールについて紹介していきます。 また、本ツールで実装されている静的解析技術(主にフロー解析)について解説します。

CEDEC2024での発表

発表資料はこちらにあるので、本ブログでは概要だけ紹介します。

本発表では、社内のあるゲーム開発プロジェクトにC#の静的解析ツールを開発・導入した事例を紹介しました。

静的解析ツールはRoslynアナライザーとして実装しました。 本ツールは構文解析だけでなくフロー解析を行っていて、文の実行順序や変数の定義と参照の関係を認識できます(この詳細については後述します)。

弊社では本ツール以外にも複数のRoslynアナライザーを導入していて、不具合の早期発見に役立てています。 これらのツールで検出したコードの情報をクラウド上に蓄積しダッシュボード化することで、コードの品質を観測できるようにしています。

公開した静的解析ツール

今回公開したMustAwaitAnalyzerTaskUniTaskawait忘れを検出する静的解析ツールです(以後、Taskを例に説明しますがUniTaskでも同様です)。

C#では、Taskクラスとasync/awaitキーワードを利用することで非同期処理を簡潔に記述できます。 たとえば下記のようなコードで、DeleteAsyncメソッドを実行しながら別の処理を実行できます。

public async Task DoAsync()
{
    using var client = new HttpClient();
    var task = client.DeleteAsync("https://example.com/hoge");

    // 何か別の処理をする

    await task;
}

async/awaitの利点の1つは、非同期に実行したメソッドで例外が発生したとき、その呼び出し元に例外を伝播してくれるという点です。 上記のコードの場合、DeleteAsyncメソッドで例外が発生すると、その呼び出し元であるDoAsyncメソッドに伝播され例外を発生させます。

しかし、awaitを記述せず、かつTaskクラスのExceptionプロパティをチェックしなかった場合、呼び出し先の例外が捕捉されません。 このようなコードは意図しない挙動を引き起こすことがあります。

public async Task DoAsync()
{
    using var client = new HttpClient();
    var task = client.DeleteAsync("https://example.com/hoge");

    // 何か別の処理をする

    // await task; awaitを忘れると、DeleteAsyncで例外が発生しても捕捉されない
}

このようなawait忘れを検知する静的解析ツールMustAwaitAnalyzerを開発しました。

フロー解析の導入

開発当初は構文解析によってawait忘れを検知していました(発表スライドのこのあたり)。 構文木を探索し、Task型の変数やTask型を返すメソッド呼び出しの親ノードがawait式であれば問題なし、そうでなければ警告するという検知ロジックです。 しかし、このロジックでは正しく検知できないことがありました。 たとえば以下のようなコードです。

async Task MultiTask(bool b1)
{
    var list = new List<Task>(); // s1
    var task1 = DoAsync();       // s2
    if (b1)                      // s3
    {
        var task2 = DoAsync();   // s4
        list.Add(task2);         // s5
    }
    list.Add(task1);             // s6
    await Task.WhenAll(list);    // s7
}

この例の場合、先述の検知ロジックではs2やs4のDoAsyncメソッドの呼び出しがawaitされていないという警告が出力されます。 しかし実際には、DoAsyncメソッドが返すTaskオブジェクトがリストに格納され、それらをs7でまとめてawaitするという問題のないコードです。 問題ないコードだと正しく判断するためには、以下のようにプログラムの実行の流れを追っていく必要があります(下記はs2のDoAsyncメソッドについてですが、s4でも同様です)。

  1. s2で、Task型を返すメソッドが呼び出されtask1に代入される
  2. s6で、s2で代入されたtask1がTask型のList(list)に追加(Add)される
  3. s7で、listを引数にTask.WhenAllメソッドが実行されている
  4. s7で、そのTask.WhenAllがawaitされている

このように、ある文の実行が変数を経由して別の文の実行に影響を与えるという依存関係を明らかにする必要があります。 これを実現する静的解析技術がフロー解析(flow analysis)です。

フロー解析には制御フロー解析とデータフロー解析の大きく2種類があります。 この2種類のフロー解析について説明します(詳細を知りたい方は末尾のリファレンスも参照してください)。 フロー解析でよく出てくる用語も紹介しながら記述しているので、コードリーディングや文献調査の際に参考になればと思います。

ちなみに、MustAwaitAnalyzerのフロー解析の実装はこのあたりです。

制御フロー解析

制御フロー解析では、文の実行順序、分岐、合流を解析し、それらを有向グラフで表現します。 下図はMultiTaskメソッドの例です。

このグラフを制御フローグラフ(control flow graph)と言います。 制御フローグラフの各ノードは、その途中に分岐も合流もない文の列になっています。 たとえばノードB1はs1, s2, s3で構成されていますが、s3から分岐が始まるためs4からは別のノードB2になっています。 また、s6がその分岐の合流地点となるため、これも別のノードB3になっています。 このノードの単位を基本ブロック(basic block)と言います。

制御フローグラフを見れば文の実行順序が分かります。 基本ブロック内は上から下の順で実行されます。基本ブロック間は辺の接続元から接続先の順で実行されます。

MustAwaitAnalyzerの目的では、制御フローグラフはデータフロー解析のための準備という位置づけですが、 制御フローグラフだけで検出できる問題もあります。 たとえば実行されることのないコードの検出です。 C#ではCS0162としてこの問題が警告されますが、これは制御フローグラフを探索することで分かります。 Entryを起点に辺をたどっていき、到達できなかったノードが実行されないコードです。

Roslynでは制御フローグラフをモデル化したクラスControlFlowGraphが用意されています。 MustAwaitAnalyzerでもこのクラスを利用しています。

データフロー解析

データフロー解析では、ある代入文で定義された変数の値がどこで参照されるかという関係を解析します。 ある代入文pとある参照文qがあり、文pで定義された値を文qで参照するとき、pの定義がqに到達する(reach)と言います。 この到達の関係を明らかにするために制御フローグラフを使います。

変数xを定義する文pと参照する文qが同じ基本ブロックにあれば、qから最も近いpがqに到達します。 たとえばMultiTaskメソッドの変数task2はs4で定義され、s5で参照されます。 これは、基本ブロックにはその途中に分岐も合流もないという性質から導けます。 仮にs4とs5の間にtask2を定義する文sxがあった場合、sxがs5に到達し、s4の定義は無効になります。 そのため「最も近い」という条件が入っています。

変数xを定義する文pと参照する文qが異なる基本ブロックにある場合は、辺の接続元の基本ブロックにある定義文から接続先の基本ブロックにある参照文に到達します。 たとえばB1のs1で定義されたlistが到達するのはB2とB3の参照文です。つまり、s5, s6, s7になります。 また、s2で定義されたtask1が到達するのはs6です(B2にはtask1の参照文がない)。 ただし、定義文のある基本ブロックBxから参照文のある基本ブロックByに至るまでに同じ変数の定義文があった場合、Bxの定義はByに到達しません。 たとえば、仮にB1とB3の間に別の基本ブロックがあり、そこでtask1が定義されていたらs2はs6に到達しません。 このような計算手順は定式化されていてデータフロー方程式(data flow equation)と呼ばれています。

以上の手順で到達の関係を解析すれば、先述したプログラムの実行の流れを機械的に追うことができます。

  1. s2で、Task型を返すメソッドが呼び出されtask1に代入される
  2. s6で、s2で代入されたtask1がTask型のList(list)に追加(Add)される
  3. s7で、listを引数にTask.WhenAllメソッドが実行されている
  4. s7で、そのTask.WhenAllがawaitされている

4は構文解析で分かりますが、1から3の順で実行されることは制御フローグラフから分かります。 また、1で代入した変数task1が2でlistに追加されるという流れは、s2の定義がs6に到達することに対応しています。

Roslynでは、どの文でどの変数を定義および参照するかを取得できます(AnalyzeDataFlowメソッド)。 MustAwaitAnalyzerでもこのクラスを利用しています。

終わりに

フロー解析を取り入れた静的解析ツールは現状あまり多くないかもしれませんが、これまでレビューに頼るしかなかった部分を自動化できる可能性があります。 フロー解析は構文解析よりも実装コストがかかることが多いのですが、RoslynのAPIがあるおかげでかなり省力化できます。 今回公開したOSSに限らず、このような静的解析ツールを広めていきたいと考えています。

リファレンス

Android Test Night #10を開催します!

SWETグループ、23新卒の若松です。

今回、2024/12/12(木)にAndroid Test Night #10をハイブリット開催します。2024年2回目のAndroid Test Nightになります!

10回目の開催となる今回は、次の方々に登壇していただき、Androidのテストについての知見を共有していただきます。

  • 納庄 宏明さん:Compose UIテストを使った統合テスト:Data LayerからUIまで繋げてテストする
  • chigichan24さん:不具合調査とTest
  • mhidakaさん:Composeで便利なテスト

発表概要

納庄 宏明:「Compose UIテストを使った統合テスト:Data LayerからUIまで繋げてテストする」

忠実度の高い統合テストを自動化できれば、リファクタリングしやすくなり、バグの検知力も向上します。反面テストが期待に反する結果になったときのデバッグで苦労することがあります。本発表では統合テストの難しさに対応する方法を紹介します。

Robolectric/Roborazzi/Hilt

chigichan24:「不具合調査とTest」

Androidはサポートするべきバージョン、デバイスが多いため、開発者が意図しなかった不具合が発生することがあります。 不具合が発生したときに、これ以上同じような不具合を発生させないようにするために、どのように対応していくとよいか、主にテストの側面から話します。 また、不具合が発生していることを早期に発見するためにできることも合わせて話します。

mhidaka:「Composeで便利なテスト」

フルCompose環境でのテスティング手法やアプリ開発環境について、手間と効果をくらべてコスパがいい品質向上のプラクティスを発表します。

終わりに

Androidのテストについて興味がある方であれば、どなたでも参加いただけます。 日々触れている方、気にはなっているけど触ったことない方、他の会社の話を聞いてみたい方など、ぜひ奮ってご参加ください!オフライン限定になりますが、懇親会も予定しています。2024/12/12のAndroid Test Night #10でみなさんにお会いできるのを楽しみにしています!

PFDとPFD Draw Toolの紹介


こんにちは、SWETの伊藤(@akito0107)です。

SWETが所属する品質管理部では開発プロセスや検証プロセスなどの業務をProcess Flow Diagram(PFD)を使って可視化し、 チーム全体の認識合わせや業務効率化に活用しています。

この記事ではPFDそのものやPFDを用いた業務可視化の実例を紹介します。 その後、SWETで開発しているPFDを記述するためのツール、PFD Draw Toolを紹介します。

PFD(Process Flow Diagram)とは

PFDとは清水吉男氏がDFD(Data Flow Diagram)を基にして、人が行う作業に使えるようにアレンジしたものです[1]。

PFDでは開発プロセスや検証プロセスなどの業務プロセスを、成果物とプロセス(1つ以上の成果物を受け取って異なる成果物へ変換する操作)に注目して可視化します。

ここでは具体例を用いつつ、PFDの書き方と構成要素について説明をします。

注:ここからの説明は、DeNAの品質管理部で用いているPFDの説明になります。オリジナルのものとは一部表現が異なっています。

下にソフトウェア開発のプロセスの例をPFDで記述しました[2]。 このPFDでは、初期成果物の要求(=ソフトウェアで実現したいこと)から始まり、仕様策定、設計、実装を経て最終成果物のソフトウェアまで至る様子が表現されています。

図1: 開発プロセスのPFDの例

図1: 開発プロセスのPFDの例

PFDの構成要素の説明をします。 図1を見て分かるとおり、PFDには次の4つの構成要素があります。

要素 画像 説明
成果物
成果物
プロセスの入力または出力となる具体的なものを表し、四角で示します。成果物ごとに一意のIDが付与されます。
プロセス
プロセス
入力を出力に変換する作業または操作を表し、丸で示します。作業は手動で行われることもあるし、自動で実行されることもあります。プロセスごとに一意のIDが付与されます。入出力がないプロセスは存在しません。
矢印
矢印
成果物とプロセスの依存関係を表現します。
点線矢印
点線矢印
初回の実行では入力がないことを示し、成果物からプロセスに向けて使用されます。

PFDでは成果物やプロセスの依存関係を矢印で表現します。 たとえば、図1のP3はA2、A3に依存していますし、A3はP2に依存しています。これはP3を開始するためにはA2、A3の成果物が揃っていることが前提条件となることを表しています。

また、品質管理部では、メインとなる図に加え、成果物・プロセスそれぞれに要素表を用意しています[3]。 要素表とはPFDに書き切れない詳細な説明を記載する表で、 たとえば図1のPFDに対応する成果物の要素表は下のようになります。

ID 名前 概要
A1 要求 PRDとして企画側から提供されるもの
A2 仕様 画面の動作イメージおよび制約事項などが記載されているドキュメント
A3 設計ドキュメント API定義、シーケンス図、状態遷移図、DB設計を含んだドキュメント
A4 ソフトウェア ビルド済みで実行可能な状態のソフトウェア。スモークテストを完了させておく。
A5 実装中に見つかった設計のミス 実装の過程で見つかった設計のミスもしくは改善点。ドキュメントに反映させ、その後実装を修正する。

成果物の定義を詳細に書き下すことにより、成果物についての認識のずれが発生していないかを確かめることができます。 たとえば、A3はAPI定義、シーケンス図、状態遷移図、DB設計を含んだドキュメント と定義しています。 今回は例示のため簡単に書いていますが、 定義や成果物の完了条件などをあらかじめ明確にして作業者間で認識をそろえておくことにより、いざ実際に開発を進めた際にドキュメントの作成漏れや作業の漏れを防ぐことができます (なお、プロセスについても同様に要素表を作成します)。

より詳細なPFDの記述方法に興味がある方は[1]等を参照してください。

PFDのメリット

さて、PFDの大まかなルールと記法がわかったところで、PFDのメリットを考えてみましょう。

業務プロセスを可視化すること自体の有用性はさまざまな場所で語られていますが、改めて整理します。 特に次の2つが挙げられます。

  1. 業務の流れを誰でも把握できるようにする。
  2. 業務改善の土台になる。

たとえば、1については新任者がチームに入ってきたときの立ち上がりや、チーム内で認識を揃えるのに必要な要素です。 2について、それぞれの作業がどう繋がってるのかを観察することにより、業務の冗長性を排除したり、品質に問題がある作業をあぶり出して改善作業を行うことができます。

業務プロセスの可視化は、PFD以外にフローチャートやバリューストリームマッピングなど、さまざまな手法が存在しています。 それらに比べると、PFDは成果物に注目する、という特徴があります。

たとえばフローチャートでは業務の手続きに注目し、それらのアウトプットである「成果物」は省略して記述されます。 上の図1をフローチャートで書くと次のようになります。

フローチャートの例

PFDで書く場合に比べ、簡潔に記述できてはいますが、作業の順番は理解できてもそれらの関連性についての情報は希薄になっています。

いざ実行してみると、作業のゴールイメージがずれていたり、成果物不足で作業同士がつながらなかったりといったことがよくあります。 プログラマーの方でしたらプロセスの『型』を明記する、といった方が伝わりやすいかもしれませんが、 PFDではプロセスだけではなく成果物に注目することにより作業の目的とそれらの関係をより明確にでき、 プロセスの実行時の不確実性の排除やチーム内外との認識齟齬を防ぐのに役立ちます。

PFDのSWETでの活用方法

PFDの一般的な説明をしたところで、SWETで活用しているPFDの具体例をいくつか紹介しようと思います。

例1: レビュープロセス

SWETの業務として、プロダクトコードのレビューがあります。 ここでのコードレビューの目的は、不具合の可能性を早期に発見するということももちろんあるのですが、 SWETメンバーのテストや対象のプログラミング言語についてのノウハウをレビューを通じて、実装者(レビュイー)に対して伝達することにあります。

SWETで行われるレビューのプロセスは次のようになります。

図2: レビュープロセスのPFD

図2: レビュープロセスのPFD

ここで注目するのは、成果物としてA4, A5のノウハウといった不定形のものや人間の脳内にしかないものを扱っているという点です。 「成果物」と書くとドキュメントやソースコードなど、具体的なものをイメージしがちですが、PFDではこのような抽象的な対象についても扱うことを許容しています。

例2: 外部勉強会の運営プロセス

それではさらに複雑な例を見てみましょう。 SWETではTest Nightなど、外部の方々を招いた勉強会を主催しています。 その際の開催や運営のプロセスを可視化したものになります。 実際のものからはかなり省略・簡略化したものになりますが、関係各所との調整や、 何をどの順番で実行しなければいけないかが明確になっています。

図3: 外部勉強会の運営プロセスのPFD

図3: 外部勉強会の運営プロセスのPFD

このような複雑な業務プロセスでもPFDを活用することでプロセスを明確に表現でき、特にチームで作業する際には共通の理解を促進するのに役立ちます。

PFD Draw Toolについて

PFDについてその概要・メリット・具体的な事例を紹介してきました。 ですが、PFDの弱点として、その記述やメンテナンスが難しいという問題点があります。

成果物・プロセスそれぞれにつける一意なIDの付与や要素表の作成がその代表的なもので、 成果物やプロセスを生成するたびにIDを編集したり、表と図の対応をそろえたりと、 とにかく人力でPFDを整合性が保たれている状態に維持するのはかなりの労力を費やします。

そこでSWETではPFDの記述をサポートするツールを作成しました。 ツールはWebベースのアプリとして実装されていて、社内の人であれば誰でもアクセスできるようにしています。

ちなみに、この記事に掲載してあるPFD(図1 ~ 3)はすべてこのツールで記述しています。

PFD Draw Toolの機能

いくつか機能があるのですが、ここでは主要な機能を3つ紹介します。

ID自動採番

成果物、プロセス生成時に自動で連番のIDを付与します。 また、ここで付与されたIDは後で自然な順序(PFDのグラフ構造の始端が若く、終端に向かうにつれ番号が増えていく)に自動で振り直すこともできます。

ID自動採番機能

要素表自動作成

成果物、プロセスを作成時に自動で要素表にも追加します。 図の方で値を修正すると、要素表に自動反映します。またその逆も自動で行います。

要素表自動作成機能

PFDのルールのチェック

PFDには、記述上のルールがいくつか存在します。 たとえば成果物と成果物は矢印で繋げない(プロセス同士についても同様)、成果物はひとつのプロセスからしか生成されない、などです。 それらのルールに反したPFDをそもそも書けないようにする仕組みが実装されています。

PFDのルールチェック機能

PFD Draw Toolの技術スタック

簡単に実装に用いた技術スタックを紹介します。

実装にはReactをベースに状態管理ライブラリとしてRedux、Canvas上のコンポーネントライブラリとしてKonvaを使っています。

Reduxを用いることにより、この手のエディターの基本機能であるUndo / Redoや、ファイルへの書き出しの実装を簡易に実装できています。

まとめ

この記事ではPFDの紹介とSWETでの活用事例、SWETで開発したPFD Draw Toolについて紹介しました。 PFDは成果物にも注目して業務プロセスを可視化することにより、それぞれのプロセスの関係を明確にし、 実行時の不確実性を抑制し、作業者間での認識齟齬を防ぐのに役に立ちます。

SWETではこのPFDを用いて各種業務の可視化や効率化に活用し、さらにPFDの記述やメンテナンスを簡易にするツールを実装しました。

今回はPFDを用いた業務の改善・効率化については触れませんでしたが、また機会がありましたら紹介させていただこうと思います。

注釈

  • [1]: 梶本 和博、派生開発推進協議会T21研究会 著 『プロセスを自在に設計するーPFDを使いこなそうー』 八木 将計、八木 香織(編集)、NextPublishing Authors Press、2021年5月29日
  • [2]: ここではPFDの説明のために簡略化した開発プロセスを記述しています。実際の開発はここに検証の工程が追加されたり、「仕様を決める」というプロセスの中にも何工程も含まれたり、かなり複雑なものとなります。
  • [3]: オリジナルのPFDでは要素表ではなく、それぞれの成果物・プロセスに定義書を記述します。

Lint Night #3を開催しました!

こんにちは、SWETの秦野です。

2024/6/7(金)に Lint Night #3 を開催しました。
本記事では、当日の発表スライドを紹介していきます。

参加者の反応

当日の様子はTogetterにまとめています。 こちら からご覧ください。

当日の動画

YouTubeにて当日のアーカイブ動画を公開しています。 www.youtube.com

発表紹介

@szkdash「lintnet - General purpose linter powered by Jsonnet」

最初の発表は @szkdash さんによる「lintnet - General purpose linter powered by Jsonnet」でした。 speakerdeck.com

ご自身が先月リリースされたlintnetについて紹介していただきました。 lintnetはJSONやYAMLなどの様々なフォーマットに対応している汎用的なLinterです。 ユーザーはLinterのルールを Jsonnet で定義し、そのJsonnetを公開すれば様々なプロジェクトで同じルールを共有できます。 ルールの共有が簡単という点が非常に魅力に感じます。

本イベント後にszkdashさんが lintnetの紹介記事 を公開されています。こちらもご覧ください。

@Linda_pp「actionlint の Linter 設計」

次の発表は @Linda_pp さんによる「actionlint の Linter 設計」でした。 speakerdeck.com

actionlintはSWETグループでも使わせてもらっていて、お世話になっているツールです。 発表ではactionlintの設計思想について解説していただきました。 CIのワークフローファイルに対するLinterであるという特徴に合わせて、気軽に使えて高速なツールを目指すという方針はとても興味深く参考になる内容でした。

@haya14busa「reviewdog を飼ったコードレビュー支援体験とその汎用的な実現方法」

続いての発表は @haya14busa さんによる「reviewdog を飼ったコードレビュー支援体験とその汎用的な実現方法」でした。 docs.google.com

reviewdogもSWETグループで使わせてもらっています。ありがとうございます! 発表ではreviewdogについて紹介していただきながら、世の中のLinterの出力形式がバラバラであるという問題についても解説していただきました。 この問題に対して、haya14busaさんが提案するフォーマットであるRDFormatが紹介されています。 Linterの出力形式にお悩みの方は必見です!

@tomoyamachi「パーサを使わないLintツール dockle」

最後の発表は @tomoyamachi さんによる「パーサを使わないLintツール dockle」でした。 paper.dropbox.com

Linterは構文解析をするものだと思いがちですが、dockleはシンプルな文字列操作でコンテナイメージの問題を検知しています。 Linterを作ってみたいけど難しそうと感じている人を後押ししてくれる内容で、Lint Nightのテーマにピッタリだったと思います。

終わりに

お忙しい中登壇していただいた発表者の皆様に感謝いたします。 また、オフライン/オンラインで参加していただいた皆様、ありがとうございました。 皆様のおかげで無事Lint Night #3を開催できました。 今後もLint Nightをよろしくお願いします!

CI/CD Test Night #7を開催しました!

こんにちは、SWETのCI/CDチームに所属している幸田(@ponkio_o)です。

2024/03/26(火)に弊社オフィス(渋谷スクランブルスクア)とオンラインのハイブリッドで CI/CD Test Night #7 を開催しました。
本記事では、当日の発表スライドを紹介していきます。

参加者の反応

当日の様子はTogetterにまとめを作成しているので こちら からご覧いただけます!

当日の動画

YouTubeにて当日のアーカイブ動画を公開しています。 www.youtube.com

発表紹介

@ponkio_o「業務で役立つ…かもしれない?!GitHub Actions Tips 集」

最初の発表は私の「業務で役立つ…かもしれない?!GitHub Actions Tips集」でした。 speakerdeck.com

GitHubとの相性がよく、便利なGitHub Actionsですが、凝ったことをしようと思うとハマるポイントがいくつかあると思っています。今回の発表では実際の業務で遭遇した様々なTipsを紹介しました。
特に動的なJobの実行とBranchProtectionの話は「役に立った」との反応をいくつかいただけたので、お役に立ててよかったです!

@szkdash「CI/CD のセキュリティや Developer Experience を改善するツールやプラクティス」

続いての発表は @szkdash さんによる「CI/CDのセキュリティやDeveloper Experienceを改善するツールやプラクティス」でした。
スライドはGoogle Slideにて公開されています。 docs.google.com

ご自身で開発されている aquatfcmt などの紹介に加え、さまざまなセキュリティのプラクティスを紹介していただきました。発表中に紹介のあった ghalintpinact は直近でも業務で使わせてもらっていたのでタイムリーな内容でした。
szkdashさんのOSSは仕事でもプライベートでも数え切れないくらい使わせてもらっていますが、どのプロダクトもDXだけでなくセキュリティまで意識されている点がすごいな〜と思っています。

@k1LoW「CI/CD があたりまえの今の時代に API テスティングツールに求められていること」

続いての発表は @k1LoW さんによる「CI/CDがあたりまえの今の時代にAPIテスティングツールに求められていること」でした。

speakerdeck.com

APIシナリオテストツールである runn の開発を通じて得たさまざまな気づきを紹介していただきました。
私も前職でrunnを利用していたのですが、今回の発表を通じて新しい情報も知ることできたので、機会があれば使ってみたいと思いました。

また今回の登壇に関するブログを執筆されているのでこちらもご覧ください!

k1low.hatenablog.com

今回の発表とはまったく関係ないですが、個人的に k1LoW/gh-do には大変お世話になっています!ありがとうございます。

@katzchum「リリース戦略を支える CI/CD パイプライン」

続いての発表は @katzchum さんによる「リリース戦略を支えるCI/CDパイプライン」でした。

runnの開発にも積極的に参加されているkatzchumさんからは、複数チームにまたがるリリースの悩みを Semantic VersioningSongmu/tagpr を使ってうまく解決された事例をデモを交えて紹介していただきました。
tagprは私も仕事とプライベートの両方で活用しており、Semantic Versioningを用いたリリース戦略は弊チームでも採用している部分があるため、とても共感できる内容でした。

終わりに

お忙しい中登壇して頂いた発表者の皆様、そして足元の悪い中、弊社オフィスまで足を運んでくださった皆様に感謝します。皆様のお陰で無事にイベントを終えることができました。
引き続きCI/CD Test Nightをよろしくお願いします。

CI/CD Test Night #7を開催します!

こんにちは、SWETでCI/CDチームの前田( @mad_p )です。

SWETでは、CI/CDに関する知識を共有することを目的として、「CI/CD Test Night」を開催しています。 約1年ぶりに、CI/CD Test Night #7をハイブリッド開催します!

今回のテーマは「CI/CDのプラクティス」についてです。 CI/CDサービスを利用してパイプラインを作成している中で、ふとしたときに「もっと効率の良い方法があるのではないか?」と考えたことはないでしょうか。断言します、私はあります! そこで今回は、 CI/CDに関するプラクティスや関連するツールの活用方法などをメインテーマとし、弊社メンバーに加え、CI/CDやツールに関する情報を多く発信しておられる以下の方々をお招きして開催いたします。

CI/CDのワークフロー作成時に手助けとなるツールや、どのようにパイプラインを構築しているのかなど、それぞれの現場での知見が多く知れる機会かと思います。 CI/CDのパイプラインを作成して運用しているが課題を持たれている方、これからCI/CDサービスを活用してパイプラインを構築しようと考えている方、すでに色々と知見を持ち課題などを解決している方この会を通して皆さんと多くの意見交換をしませんか。 皆様のご参加をお待ちしております!

オフライン限定になりますが、懇親会も予定しています。 3/26のCI/CD Test Night #7でみなさんにお会いできるのを楽しみにしています!

Android Test Night #9を開催しました!

SWETグループ、23新卒の若松です。

今回、2024/1/31(水)にAndroid Test Night #9をオンライン開催しました!

本記事では、今回の発表のスライドを紹介していきます。あわせて発表内容の動画も公開していますのでご確認いただければ幸いです。

参加者の反応

Android Test Night #9 で盛り上がっている様子に投稿をまとめました。

当日の登壇動画

www.youtube.com

発表スライド紹介

Kento Wakamatsu:「Roomのマイグレーションをテストする方法」

トップバッターは私で「Roomのマイグレーションをテストする方法」の発表でした。

Roomのマイグレーションをテストする方法と注意すべきことについて、業務で行った例を示しながら説明しています。マイグレーションのテストを書く際は是非参考にしてみてください。 speakerdeck.com

@sumio_tym:「Roborazzi + Jetpack Composeでスクリーンショットを撮るときに役立つTips集」

続いては、弊社SWETグループの@sumio_tymによる「Roborazzi + Jetpack Composeでスクリーンショットを撮るときに役立つTips集」の発表でした。

Robolectric(+Roborazzi)でJetpack Composeのスクリーンショットテストを書くにあたり、役立つTipsについて紹介しています。 speakerdeck.com

@saikiiiji:「ViewModelのUnitTest難しすぎ問題」

3番目は、株式会社U-NEXTの@saikiiiji様による「ViewModelのUnitTest難しすぎ問題」の発表でした。

Android開発におけるViewModelで、ユニットテストを効率よく書くための役にたつテクニックについて紹介していただきました。ViewModelでテストしたいロジックを別クラスに書き出すだけでテストしやすくなるというのは驚きでした。 www.slideshare.net

また、他にもTDDに関する発表を行なったり、RaMviを使ったテーブル駆動開発についてのブログを書かれたりしていらっしゃるので、要チェックです! t.co t.co

@hkusu_:「SARIFファイルを利用したAndroidの静的解析」

最後に、株式会社ゆめみの@hkusu_様による「Androidの静的解析におけるSARIFファイルの活用」の発表でした。

SARIFファイルをGitHub ActionsとGitHub Code scanningを用いてAndroidアプリの静的解析ツールを実行する方法について紹介していただきました。GitHub Actionsで各種静的解析ツールとGitHub Code scanningの連携方法についてかなり詳しく説明されているので、導入する際は是非参考にしたいと思いました。 speakerdeck.com

終わりに

今回登壇していただいた皆様、参加していただいた皆様のおかげで、無事Android Test Night #9を終えることができました。大変感謝しております。 Android Test Nightは、今後も定期的にイベントを開催する予定ですので、今回参加していただいた方々、参加できなかった方々も次回お会いしましょう!