単体テストソムリエ になろう︕ WACATE実⾏委員 ⼭⼝

単体テスト ■ みなさん知ってますか︖

単体テスト ■ 困ってるなぁ・・・ってことありますか︖ – 直感的に「これは単体テストで⾒つかっていいんじゃ︖」と思うことがある – むしろ開発者によってやってることが違う気がする

単体テストってわかりにくい ■ プロジェクトで指しているテストが全然違う ■ むしろ個⼈で違う 画⾯だ︕ クラスだわ︕ ⾃動だわ︕ 画⾯で⾃動と か妄想⼄︕

単体テスト ■ JSTQBより – コンポーネントテスト（ユニットテストとも呼ばれる）︓コンポーネント を単独でテストすることに 焦点を当てる。コンポーネントテストは、テス トハーネス、またはユニットテストフレームワークのよ うな特定のサポー トを必要とすることが多い。コンポーネントテストは、通常、開発者が開 発環境で⾏う。

単体テスト ■ JSTQBより – コンポーネントテスト（ユニットテストとも呼ばれる）︓コンポー ネントを単独でテストすることに 焦点を当てる。コンポーネントテストは、 テストハーネス、またはユニットテストフレームワークのよ うな特定のサ ポートを必要とすることが多い。コンポーネントテストは、通常、開発者 が開発環境で⾏う。 実際の現場ではプログラムごと、画⾯ごと、振る舞い単位（コンポー ネントの集合体）で⾏われることも多く、これは単体テストと多くの 現場で呼ばれているものの説明ではない （おそらくコンポーネントテスト＝単体テストになってほしいという思いの表明）

単体テスト ■ SWEBOK – ユニットテスティング︓別々にテストできるソフトウェア構成要 素を切り離し、それぞれの働き（functioning）を検証する。前後関係 （context）に依存して、これらは独⽴したサブプログラミングであったり、 密接に結合された単位から作られた、より巨⼤なコンポーネントだったり する。 ■ SQuBok – 単体テスト︓モジュールやクラスなどテストが実施可能な部分をテス トする。 （アーキテクチャや単体テストツールを駆使してプログラムの最⼩単位（コンポーネント）ごとに テストするのをデファクトスタンダードにしたいけど実態は） テストできる最⼩単位を切り離して検証するテスト

システムテストなら。。 ■ テスト設計 – ⽂献にテストタイプとかの説明がもっと詳しく書いてある ■ 多くの場合、エンドツーエンドのタスクに対する機能テストや品質特性に対す る⾮ 機能テストといったシステムやプロダクト全体の振る舞いや能⼒の全般 に焦点を当てる。⼀部の⾮機能 品質特性については、本番相当のテスト環境 において、すべて揃ったシステムでテストすることが望ま しい（例えば、使 ⽤性テスト）。サブシステムのシミュレーションを使⽤することも可能である。 シス テムテストは、システムの仕様に関連するものであり、独⽴したテスト チームによって実施されること がある（JSTQBより）。 – テスト技法に⾔及する⽂献の多くがシステムテストに類するテストを事例 としており、イメージしやすい。 ■ ⼈事管理システム（はじめて学ぶテスト技法） ■ Webサイトの⾒直し（マインドマップから始まるテストウェアテスト）

単体テストだと。。 ■ 古典は「じゃあどうやってテストするのよ︕」って本が多い – ホワイトボックステストっていいますが・・・ – スタブ・ドライバ使うんです︕って書いてあるけどそれ、どうやって作るの︖ – 書いてあっても製品コードが古すぎて参考にならない。 ■ 最近の本はいきなり「コードで書くもの︕⼿動何それおいしいんですか︖」 「ツール使え︕」って前提の本が多い – ⾃動テストをデファクトスタンダードにしたいという思想が強い。 – ⼿段に偏っていることが多い。 – 古典との連続性がなく、概念を把握しにくい。 – 最近「単体テストもブラックボックステストでかくもの（キリッ）」までものが 出てきてもはや何⾔ってるかわからない。

単体テストは知っとくべき ■ ⾃分のテストの前にどんなテストが⾏われていたかは把握しておく必要がある – ⾃分のテストを計画・分析・設計するときに必要 ■ 「これまで何がテストされてきたか」 ■ 「どういうバグが残っていることが想定されるか」 – バグやテスト結果の分析に必要 ■ 「なぜこのバグが残っているのか」 ■ 「これからどうすればいいのか」

単体テストソムリエになろう︕

⾃⼰紹介 ■ ⼭⼝ 寛⼦ ■ SN︓@scarletplover ■ ⾦融系の会社で⾦融系じゃないSIer ■ どちらかというと猫派（本当は狐派） ■ 最近キックボクシング始めました。

このセッションでやりたいこと ■ 概念としての単体テストを捉えられるようになること ■ 単体テストの勉強の仕⽅がわかる ■ 最新の単体テスト技術はほっとんど出てきませんごめんなさい。

このセッションの内容 ■ 単体テストとは – 単体テストとは – 単体テストで重要な要素 ■ 単体テストソムリエになろう（ワーク） ■ 最後に

単体テストとは

いきなりワーク ■ 基本、このセッションのワークはペアで⾏います。 ■ 班で２⼈×３グループに分かれてください︕ ⾮公開

単体テスト ■ テストは1968年のNATOソフトウェア⼯学会議で「ソフトウェア危機」って⾔葉が出てきてか ら本格的に語られるようになったっぽい。 ■ しかし、1960年代は⼯程は「テスト」のみで、テストレベルみたいなものは存在しなかっ たっぽい。 ■ 1979年のマイヤーズの「ソフトウェア・テストの技法」くらいで「仕様に対するテスト」と いう考え⽅が出てきて、「モジュールテスト」って⾔葉が誕⽣したっぽい。 ■ 現在はV字モデルをもとに単体テストが語られる場合が多い 要求 基本設計 詳細設計 実装 ④ 受け⼊れテスト ③ システムテスト ② 統合テスト ① コンポーネントテスト リグレッションテスト コードレビュー ソースコード

単体テストとは テストできる最⼩単位を切り離して検証するテスト 「最⼩の」「細かい」など、とても抽象的であるうえに、プロダクトのアー キテクチャに左右される。 アーキテクチャの末端をテストすることとなり、技術の変遷の影響を受けや すく、体系的に本質を学ぶのが難しい。 プログラミングにおいて、プログラマが決めていることは意外と多い。 プロジェクト・個⼈ごとに違うテストになりやすい。

単体テストでの⼤事な要素 ■ テストなので、「テスト対象＝どの単位でテストするか」「ど こに着⽬してテストを作成するか︖」が⼤事 ■ 単体テストはプログラムの中のことを確認しなくてはならないので、何 かとツールが必要。よって「どう実施するか」も重要になる。実施 ⽅法によってテスト対象や着⽬点が制約を受けることもしばしばある。 ■ 現場によっては「単体テスト」に「統合テスト」を含んでいる場合もあ る。また静的テストで実装内容を確認しているかどうかによって単体テ ストのケースが変わることがある。よって「前後のテスト⼯程」を 勘案する必要がある。 ■ プロジェクトのプログラミング⼯程は１⼈じゃないため、上記の事項に おいて「どこまで共有・ルール化しているか」でプロジェクトと しての単体テストの質が変わる。

単体テストの⼤事な要素 どの単位でテストするか どこに着⽬してテストを作成するか︖ どう実施するか 前後のテスト⼯程は何か チームで共有しているか

単体テストの⼤事な要素 どの単位でテストするか どこに着⽬してテストを作成するか︖ どう実施するか 前後のテスト⼯程は何か チームで共有しているか

どの単位でテストするか ■ 基本的には「モジュール」だが・・・ – クラス・関数・コンポーネント・・・ – コンパイルされたプログラムの場合もある。 ■ 時代によって凝集性が上がり結合度が下がっている。 「モジュール」の中⾝がどんなものかは把握しておく必要がある。 – 1960年以前︓芸術品としてのプログラム・・・プログラマ頼み – 1960年代〜︓構造化プログラミング・・・制御構造 ブロック化 – 1990年代〜︓オブジェクト指向・・・カプセル化 再利⽤ ? メイン ⼊⼒項⽬のチェッ ク 料⾦計算 印刷 メインルーチン ⼊⼒チェック 料⾦計算 印刷 メイン ⼊⼒項⽬のチェッ ク 料⾦計算 印刷 メインルーチン ⼊⼒チェック 料⾦計算 印刷 インプット ビジネス ロジック アウトプット オブザーバー 属性 操作 ビュー クラス 属性 操作 コントローラー クラス 属性 操作 モデル クラス 属性 操作 モデル クラス 属性 操作

単位の種類 ■ モジュールにも⾊々ある – 画⾯ – DBに接続する – ビジネスロジック – 処理の順番を管理する ■ モジュールによって単体テストの意 味やしやすさが違う – ビジネスロジックはロジック 単位でテストできる – 画⾯はどっかで⼈間の⽬視が 必要 – DBは実際にDBに繋がないとテ ストできない部分がある。 ビジネスロジックな どは単独でテストし やすい コントローラーやDB 周り、UI周り は単体でテストしに くい

単位が「複数」なことも ■ 単⼀のモジュール・クラス・プログラムじゃないこともある。 お⾦ロジック ドル通貨ロ ジック 振る舞い単位 （テスト駆動開発より⾦額計算） フラン通貨ロ ジック

単体テストの要素 どの単位でテストするか どこに着⽬してテストを作成するか︖ どう実施するか 前後のテスト⼯程は何か チームで共有しているか

どこに着⽬してテストするか ■ 単体テストで確認する仕様 – ビジネスロジック – UIの⾒た⽬ ■ 単体テストで確認するアーキテクチャ – 他の単位とのインターフェース（クラス間など） – 他の単位とのコミュニケーション（クラス呼び出しなど） – 状態の変化（セッション、画⾯の状態など） ■ 開発者が決める実装内容 – メソッド・変数の名前 – 処理の細かいロジック – 処理順序

どこに着⽬してテストするか ■ 単体テストで確認する仕様 – ビジネスロジック – UIの⾒た⽬ ■ 単体テストで確認するアーキテクチャ – 他の単位とのインターフェース（クラス間など） – 他の単位とのコミュニケーション（クラス呼び出しなど） – 状態の変化（セッション、画⾯の状態など） ■ 開発者が決める実装内容 – メソッド・変数の名前 – 処理の細かいロジック – 処理順序 ここにフォーカスしたテス トケースを作成するのが 原則

どこに着⽬してテストするか ■ 単体テストで確認する仕様 – ビジネスロジック – UIの⾒た⽬ ■ 単体テストで確認するアーキテクチャ – 他の単位とのインターフェース（クラス間など） – 他の単位とのコミュニケーション（クラス呼び出しなど） – 状態の変化（セッション、画⾯の状態など） ■ 開発者が決める実装内容 – メソッド・変数の名前 – 処理の細かいロジック – 処理順序 基本はアーキテクチャとし てのインターフェースやコ ミュニケーション、状態変 化に落ちる テストケースはアーキテク チャのインターフェースに 依拠するはず

どこに着⽬してテストするか ■ 単体テストで確認する仕様 – ビジネスロジック – UIの⾒た⽬ ■ 単体テストで確認するアーキテクチャ – 他の単位とのインターフェース（クラス間など） – 他の単位とのコミュニケーション（クラス呼び出しなど） – 状態の変化（セッション、画⾯の状態など） ■ 開発者が決める実装内容 – メソッド・変数の名前 – 処理の細かいロジック – 処理順序 ここはいわば実装部分。 変更が多いため、ここを起 点にテストをすると保守性 が低くなる

どこに着⽬してテストするか ■ 単体テストで確認する仕様 – ビジネスロジック – UIの⾒た⽬ ■ 単体テストで確認するアーキテクチャ – 他の単位とのインターフェース（クラス間など） – 他の単位とのコミュニケーション（クラス呼び出しなど） – 状態の変化（セッション、画⾯の状態など） ■ 開発者が決める実装内容 – メソッド・変数の名前 – 処理の細かいロジック – 処理順序 ここにフォーカスしたテス トケースを作成するのが 原則

複雑さをどうテストするか ■ 開発者が決める実装内容のみにフォーカスしたテストをして はいけないが、問題がないかの検証は必要 →単体テストまでに潰しておく必要がある ■ 複雑さをどうテストするか – 基本は全てテストで実⾏されていない経路がないことを 確認する（カバレッジ）。 ■ 命令網羅︓ – すべての命令が少なくとも⼀回は実⾏されるようにテ ストを設計する。 ■ 分岐網羅︓ – 判定条件の結果として、真になる場合と偽になる場合 がそれぞれ少なくとも⼀回は出現するようにテストを 設計する。 ■ 条件網羅︓ – 条件判定における個々の条件について、すべての真偽 が少なくとも１回は出現するようにテストを設計する。

複雑さをどうテストするか ■ カバレッジは確保してるけどテストが不⼗分になるパターンに注意 – 組み合わせが⼗分にテストできていない – 境界値分析ができてない if(x == true || y == true){ return true; //x,yのどちらかが真だったら真 //x、y両⽅のパターンのテスト 要 } if(hoge >= 1 && hoge <=10){ return true; //1以上10以下だったら真 //境界値分析が必要 }

単体テストの要素 どの単位でテストするか どこに着⽬してテストを作成するか︖ どう実施するか 前後のテスト⼯程は何か チームで共有しているか

どう実施するか ■ ⼿動か⾃動か – UI関連はどっかで⽬視が必要になる場⾯ が存在する – ⾃動については「何でテストするか」 でできることがだいぶ変わる ■ 昔は頑張って呼び出し元プログラムを 偽造できるようにシステムを作成しな ければ⾃動テストできなかった。 ■ 今はmockなどの技術が発達し、そこま で頑張って意識しなくても⾃動テスト できるようになった。 ■ より⼩さいところからテストできるよ うになるのが理想。 ■ テスト記録ツール – 単体テストツールには⾃動でついてる が⼿動でもテスト内容を記録し、カバ レッジ率を計ってくれるものが存在。 テストした いクラス 呼ばれるモ ジュール 呼ばれるモ ジュール mockで偽造する

単体テストの要素 どの単位でテストするか どこに着⽬してテストを作成するか︖ どう実施するか 前後のテスト⼯程は何か チームで共有しているか

前後のテスト⼯程について ■ 単体の統合について – 現場では「モジュールテスト＋統合テスト」を単体テストと呼んでいると ころも多い ■ マイヤーズでは「モジュールテスト」の章にモジュールテスト ＋ 統合テ ストが書かれている。 – テストの実施⽅法によってはモジュールテストがやりにくいところもある。 ■ DB周りや画⾯では統合した上でテストをすることが推奨されるクラスも ある – ⼤事なのは「最⼩の単位」の統合をどう考えているのか ボトムアップでの 統合 トップダウンでの 統合

前後のテスト⼯程について ■ 静的テストについて – 開発者が決める仕様については、開発者のコードレビューを実施している ことが望ましい – コードの書き⽅によって、テスト内容が変わる。 配列を結合する例 let ⼊⼒配列 = [“あ”,”い”,”う”,”え”,”お”]; let 結果; for(let i = 0; i <5 ;i++){ 結果=結果+⼊⼒配列[i]; //ぐるぐる回して結合 } return 結果; let ⼊⼒配列 = [“あ”,”い”,”う”,”え”,”お”]; let 結果=⼊⼒配列.join(“”);

単体テストの重要な要素 どの単位でテストするか どこに着⽬してテストを作成するか︖ どう実施するか 前後のテスト⼯程は何か チームで共有しているか

テストの内容を共有しているか ■ 世の中には「テスト内容は開発者に任せている」「⾃動テストができる⼈だけ ⾃動テストをやっている」という現場が存在する。 ■ テストの単位、着眼点、⼿段についてチームでどこまで平仄をとっているかは チーム次第である。 – ⾃動テストを必ずやる。コードカバレッジ100% – テストを⾏う単位ややる内容、粒度は決まっているが⼿段は決まっていな いetc… ■ また決められた単体テストのルールを守っているかをどう確認しているかも チームによって違う。 – コードレビュー – テスト仕様書レビュー – エビデンス確認

単体テストの重要な要素 どの単位でテストするか どこに着⽬してテストを作成するか︖ どう実施するか 前後のテスト⼯程は何か チームで共有しているか

単体テストの重要な要素 どの単位でテストするか どこに着⽬してテストを作成するか︖ どう実施するか 前後のテスト⼯程は何か チームで共有しているか 単体テストの内容を整理し、問題点や改善点を⾒出せる︕

チームレジェンドの単体テストの例 ■ チーム︓ クライアントサーバーシステムで画⾯側のWindowsフォームを作成。 ■ 困りごと︓ 直感的に単体テスト（開発者テスト）で出るバグがシステムテストで出ている。 ■ 単体テスト︓ 単体テストの単位 画⾯ごとのテスト。ビジネスロジックも基本は画⾯ごと。 ⼿段 ⼿動。 着眼点 画⾯の⼊⼒情報と画⾯状態に着⽬してテストケースを作成。 テスト仕様書を作成してテストしている。組み合わせも考慮さ れている。 次のテスト⼯程 システムテスト 共有 上記事項については共有されており、テスト仕様書を業務SEが レビューしている。 コードのカバレッジが図られていないため、テストされてないコード上の分岐があるのでは︖ 画⾯ごとではなく、ロジックごとにテストができるようにするのが理想。 せめてテスト記録ツールを⼊れるなどして、単体テストがしやすい環境にするのが良い。 ー

チーム最近の単体テストの例 ■ チーム︓ WEBサービスのフロントエンドをREACTで組んでいる。 ■ 困りごと︓ 直感的に単体テスト（開発者テスト）で出るバグがシステムテストで出ている。 ■ 単体テスト︓ 単体テストの単位 WEBのUI画⾯部品（⼊⼒フォーム部分とか）ごと、ロジック部 分（APIとの接続）は関数ごと。 ⼿段 Reactのテストフレームワークで⾃動テストをやっている。 着眼点 基本はUIのインプット情報ごとにテストケースのコードをTDD で書いている。コードカバレッジ100%。 次のテスト⼯程 次がもうシステムテスト 共有 上記事項については共有されており、コードレビューもしてい る。 統合をどこでやっているか曖昧。 単体テストについて、テストとしての観点が少なく、境界値分析がやられていなのでは︖

単体テストソムリエに なろう

⾮公開︕

最後に

単体テストの重要な要素 どの単位でテストするか どこに着⽬してテストを作成するか︖ どう実施するか 前後のテスト⼯程は何か チームで共有しているか

単体テストは これからも変わっていきます ■ 単体テストは実施⽅法やソフトウェアアーキテクチャによって、テスト対象や 何をテストするかが変わってしまいます。 ■ それとなく単体テスト、ソフトウェアアーキテクチャについて継続的に学んで おくことが、システムテストをやる上で助けになります︕ 単体テストソムリエになろう︕

参考⽂献 ■ ⽇本科学技術連盟. 「ソフトウェア品質知識体系ガイド（第3版）－SQuBOK Guide V3－」. ⽇本科学技術連盟.,2020 ■ 新⾕勝利. (2013). 「ソフトウェアエンジニアリング基礎知識体系ガイド - SWEBOK V3.0 -.」 ⽇本規格協会, 2013 ■ ロバート・C・マーティン. 「クリーンアーキテクチャ ソフトウェア設計の原則とパターン」. 翔泳社, 2018. ■ NPO法⼈ASTER. 「ASTERセミナー標準テキスト」. https://www.aster.or.jp/business/seminar_text.html, (参照 2023-12ｰ18) ■ グレンフォード・J・マイヤーズ, トム・バジェット, テッド・M・トーマス, コーリー・サンドラー. 「ソフトウェア・テス トの技法」. 近代科学社, 2006. ■ 児⽟公信. 「UMLモデリングの本質」. 翔泳社, 2011. • JSTQB. 「テスト技術者資格制度 Foundation Level シラバス 」. https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J01.pdf, (Version 2023V4.0.J01) ■ ⾠⺒敬三. 「ソフトウェアテストの歴史と近年の動向」. https://www.slideshare.net/Bugler/ss-139696080, (参照 2023-12ｰ18) ■ Vladimir Khorikov,.「単体テストの考え⽅/使い⽅」(Vladimir Khorikov, 須⽥智之著) ■ 本スライドのアイコンの著作権はLeremyにあります（www.freepik.com）

おわり ご清聴ありがとうございました︕