テスト設計コンテスト'17 決勝戦聴講レポート

こんにちは！テストチームとのの（TW:@tono2587）です。
今回は2/23に参加した「テスト設計コンテスト」のことを書きます。

時間は経ってしまいましたが、初めてのテスコンだったので張り切ってレポートします！

・テスト設計コンテストとは？
・決勝戦概要
・U-30クラス
・OPENクラス
・全体講評メモ
・感想など

テスト設計コンテストとは？

名前だけは聞いたことがあったのですが、いったいどんなコンテストなのかは知りませんでした。一緒におさらいしましょう！
簡単に言うと、「テスト設計のスキルを競い合うことで、さらに高めていきましょう！という会」な認識です。
公式サイト：http://aster.or.jp/business/contest.html
「OPENクラス（だれでも）」と「U-30クラス（30歳以下のみ）」の2つのクラスにわかれており、それぞれで予選がおこなわれた上での決勝戦となります。
わたしはチュートリアルは参加せず（知らなかった…）、この決勝戦のみ聴講で参加しました。

今回のテストベース

U-30クラス：「話題沸騰ポット」
OPENクラス：カラオケシステム

テストベース仕様、採点基準についてはコチラから↓
http://aster.or.jp/business/contest/rulebooku30.html http://aster.or.jp/business/contest/rulebook.html

決勝戦概要

◇日時
2017年2月23日（木）
10:00　U-30クラス決勝戦開始
12:30～13:30　昼休み
14:40　OPENクラス決勝戦開始
18:10　終了

◇場所：日本大学理工学部 駿河台校舎 7号館

◇参加チーム(発表順)

U-30クラス	OPENクラス
OPTiM	てすにゃんRev2
いんプレオ	紙印テスト倶楽部
ヤングレッジ	STUDIO IBURI
でこパン462	モモテツ
チームT研	わんだーズ
SHINNOSUKE
TBD

☆持ち時間は発表15分→質疑応答5分の計20分

U-30クラス

優勝 でこパン462 準優勝 SHINNOSUKE

総評メモ
井芹洋輝さん（審査委員長）より

入賞チームについて

• でこぱん462
  　テスト要求分析の発散と収束が上手だった（まとめが上手かった）
  　3つの目的でビューを分けてやっていたところがよかった
  　テストの手法を理解してつかっていた
  

• SHINNOSUKE
  　わかりやすかった
  　よく内容をみるとあれ？ってところがある
  　アーキテクチャを2つつくって片方を採用したところがおもしろいが、根拠が少ない
  

• TBD(準優勝惜しかった)
  　テスト要求分析でいろんな分析をやっている
  　新しい技術にチャレンジしているのがよいが、なぜその手法なのか、どうつながっているのか、それがみえず説得力に欠ける
  　技法、手法をつかうなら理解していることも証明できるとよい
  

U-30クラス全体について

• テスト開発プロセスの基礎ができていない

• 技術力不足
  チュートリアルで設計について説明があったけど、それを満たしていない
  手法の使い所がおかしい、正しくない
  

• 竜頭蛇尾
  分析がテストケースにまで落ちていない
  テスト設計は、「テスト」が成果物であり、本質。
  「テスト」をよくすることが一番で、そのためにやっている。
  

• テストの厚みの分析が足りない
  根拠の分析が弱い。
  「なにを」テストするかはできているが「どこまで」テストするかが足りない
  

上記の改善について

• 品質 についてよく考えて下さい。理解してください。
  ポットに対してテストが仕様書どおりではそもそもテストが足りない。
  （倒れる危険があったり、子どもがつかう、という前提がある。）
  

• 「よいテスト」について考えてください
  保守性の高いテスト、マネジメントが高いテスト、等
  テストの内部品質を工夫しましょう
  

• 各「技」はしっかり身につけてください
  技ばかりにこだわってはいけない。それをつかってこそ
  

OPENクラス

優勝 STUDIO IBURI 準優勝 わんだーズ

総評メモ
鈴木三紀夫さん、湯本剛さんより

• 成果物をみて
  とんでもない成果物の量で圧倒しているチームもあったが、それは本当によいかどうか
  
• アーキテクチャはいろんなビューでみなければいけない。
  どう組み合わせたら品質がよくなるのか
  いくつかのアーキテクチャのビューのなかで、順番のやつが簡単です　
  「アーキテクチャ設計」とは…をよく考える
  
• アジャイル開発にチャレンジするなら中途半端ではなく、それについてもしっかり勉強しておかないといけない
  
• 「用語」をしっかりつかうこと。
  一般的な使い方をしたほうがよい。発表にそれぞれ違う定義でつかわれている。この発表ではこうです、という定義がされていてもいつもと違う使い方だと誤解しそうになる
  

全体講評メモ

西康晴さん（審査委員長）より

• テスコンはじめの4年は主に「テスト観点」で勝負がついていた。
  そこからテスト要求分析の技術がついてきて、2年くらい前からテストアーキテクチャ設計の質で勝負が決まるようになってきた。
  

• 設計方針とはなんなのか をしっかり考える
  ものの設計とは何か?
  車輪で走るような自転車の設計、とかはわかりやすいが、じゃあ「テスト」の設計は？？？
  テストの設計は何が動くのかよくわからないからソフトウェア設計よりも難しい。　　
  参加者みんなで技術力をアップさせていっている。
  

• テストレベル、テストタイプ などの定義は世界にもある。
  それをどういう順番で並べるかを検討する方法はまだ世界にはない。
  UMLテスト 2.0とかに入ってくるかもしれない
  世界最先端です！
  

• 今回はテストベースが「派生製品」だった
  じゃあ次回は？自動化を考えたら設計の中身も変わってきたりするでしょう
  

• 要求分析→アーキテクチャ設計
  この流れが、過程が踏まれてない
  

• 成果物がただの日記で、「理由」「意図」がない
  やることが決まっていて、何も考えずにやったことを出せばOKがもらえる仕事になっている
  

• つかう用語、技術は理解してつかわなければならない
  自分たちの技術にする、アイデアにする、現場の工夫をコンテストの機会で整理してください
  それをフィードバックにして、自分たちの強みにする
  

感想など

• 同じテストベースを与えられているのに、成果物も発表も同じものはひとつもない
  逆に、自分たちの立ち位置の説明→設計の流れ説明→要求分析→テスト設計の流れはだいたい共通していたので、基本的なテスト設計の流れを知ることができました。
  
• プレゼン（発表）も得点に入っている
  設計した成果物だけではなくて、プレゼン内容が得点に影響するところがおもしろかったです。自分たちの設計したことを相手にわかるように説明することも、ときには必要なスキルなのだ思いました。
  
• すぐできそうなこと
  「用語」や「手法」を正しく理解すること。スキルアップには基本知識を増やすことが一番はやそう
  
• 「世界の最先端です」
  総評のこの話が一番わくわくしました！最先端技術のすぐそばにいる！
  

学んだこと

• テスト設計の基本の流れを理解しました
• テストの成果物も設計により様々なのだと知りました
• 十分な設計をするためにテスト設計の基本知識を身につけることが近道だと教えてもらいました
• 技術を高める機会が社外にもあることを知りました

さいごに

参加者には発表者や関係者が多い印象でしたが、聴講のみでも参加できてよかったです。
参加前にもう少しテストベースについて読んでいったり、予習していけばよかったなと思いました。（そのほうがもっと話が入りやすかったかも）
総評で「世界の最先端にいるから、本とかに自分の名前のついた手法が載ったりするかもよ（意訳）」と言われたときはすごくテンションがあがりました！
勉強のし甲斐がありますよね。これからもがんばりましょうー！！！

「最先端」が大好きなぼくのはたらく会社がこちら
www.glpgs.com

RxSwiftでMVVMの簡単なサンプルコード

こんにちは、iOS/Androidエンジニアのイバンです。

今回はアプリのアーキテクチャについての記事になります。

ソフトウエアのアーキテクチャというと様々な提案があります。iOSアプリ開発になると、アップルが推奨するMVCが一番よく使われているでしょう。

MVCと課題

MVCとはモデル（データ）・ビュー（ユーザインターフェース）・コントローラー（ロジック）という３つの責任にコンポーネントに分別するソフトウエアデザインパターンの一つです。

ビューはモデルのデータを表示して、コントローラーはビューとモデルを結びつくロジックを持っているコンポーネントです。

コントローラーは多くのUIのロジックとデータの処理のロジック両方を持ってコードの行数が簡単に何千行に上ります。iOSのMVCは実際にM + VC、つまり、ビューとコントローラーは一つになっているわけですね。

ビジネスロジックとUIロジックが混合しているとユニットテストも書きにくくなります。どちらかというと書かないようになってしまうことが多いですね。

そうなるとコードのメンテナンス性とテスト性が低下してしまい技術的負債が増え続けるパターンになりがちです。

太くなってしまうコントローラーが業界中にファットコントローラー、MVCはMassive View Controllerと呼ばれるようになってますね。

MVVMでコントローラーをダイエットさせましょう

ファットコントローラーを痩せたコントローラーにするには様々な提案がありますが、今回はMVVMを紹介したいと思います。

MVVMのパターンは下記のようにアプリのコンポーネントを分別します。

• M（モデル）：情報を持つエンティティ。
• V（ビュー）：ビューとビューコントローラを含めます。ビューを管理する以外のロジックは持ってない。
• VM（ビューモデル）：モデルを取得して表示用にデータを変換する

ビュー（コントローラー）は情報の表示とインプットの受け付けしか行いません。表示のフォーマットとインプットのアクションとその他の情報処理はビューモデルに任せます。ビューはモデルについて何も知りません。つまり、モデルのインスタンスは持ちません。

ビューモデルでは表示のロジックを行いますがUIについて何も知りません。UIKitインポートしないし、ビューのインスタンスも持ちません。 ビューモデルがモデルから取得した情報を加工してビューに提供します。

モデルは情報しか持ってないです。Swiftだとstructで実装するのは一般的です。

ここは疑問一つ挙げられることがあると思います。もしビューモデルは表示用にデータを取得して処理するなら、ビューを参照しないでどうやって画面を更新するのか？

答えはデータバインディングが仕込まれているのです。

データバインディング

データバインディングの仕組みを使うと、データがビューと連動させられてデータが変わったら自動的にビューに反映されます。

iOSはデータバインディングを対応してないので外部ライブラリを導入する必要があります。ReactKit/Bond、ReactiveCocoa、RxSwiftなどありますが、今回はRxSwiftを使います。

RxSwiftはバインディングだけではなく非同期処理やイベント処理を宣言的に書けるライブラリです。サンプルコードで使う分の解説はしますが、RxSwiftについて詳しく知りたい方は初めてのRxSwiftの発表資料や参考文献の節にあるリンクをご確認いただければ幸いです。

実際にMVVMどうなる？

サンプルアプリは単純にAPIサービスを利用して画像とテキストを取得して表示するだけですが、簡単なソースコードになりますのでMVVMはどうなっているのかわかりやすいと思います。実際のアプリには足りないところが多いですが、MVVMの基本的な仕組みの理解には十分かと思います。要求あれば今後の記事で拡張していきたいと思います。

今回はXKCDというギークなコミックサイトのAPIを使ってコミックを表示します。サンプルコードはこちらからダウンロードできます： xkcd観覧アプリ

さて、コードを追って解説しましょう。

ビュー

ComicViewControllerのviewDidLoadでviewModelの初期化とデータバインディングを行います。ViewModelからとViewModelへのバインディングは2パターンがあります。ViewModelからはビューモデル側でデータが更新になったらビューを更新するようにバインディングします。

例えば

comicViewModel.title.asDriver().drive(titleLabel.rx.text).disposed(by: disposeBag)

ビューモデルがコミックのタイトルを取得できたらRxの力でタイトルラベルに自動的に反映されるように設定します。 DriverはRxSwiftの世界で監視可能なオブジェクトのことです。最後にあるディスポーザはメモリ管理の為に追加します。

ViewModelへのところではボタンの処理（前後のコミックを依頼する）の設定と最新のコミックを取得する依頼を行いす。

ボタンのハンドリングはIBActionでも良いですが、Rxを使うとコンパクトにviewDidLoad()の中に書けます。

nextButton.rx.tap.asDriver().drive(onNext: {
    self.comicViewModel.getNextComic()
}).disposed(by: disposeBag)

実際の処理はcomicViewModelに任せます。

ビューコントローラーは以上でビューのデータバインディングとボタンのタップイベントを受けるだけのコードになります。

ビューモデル

ビューモデルはデータを取得して表示用に処理します。まずはデータバインディングできるようにRxの監視型プロパティーを用意します。例えばタイトルは下記のように宣言します。

var title: Variable<String>

ビューコントローラ側にデータバインディング（drive(..)のところ）を設定してますのでtitle.value = "タイトルです"だけで自動的にtitleLabelに反映されます。

文字列はそんな感じですが、次へ、前へのボタンは無効になったり有効になったりしますね。それはisNextEnabled/isPreviousEnabledのドライバーで実現します。監視型のVariableで最新号と観覧中のコミックを持っていて、isNextEnabledはcombineLatestでその両方が同じの場合（見ているコミックは最新）はfalseを返します。isNextEnabledはnextButtonのenabledプロパティーにバインドされてますので自動的に反映されます。

isNextEnabled = Driver.combineLatest(self.latestComicNum.asDriver(), self.currentComic.asDriver(), resultSelector: { (latestNum, current) -> Bool in
    guard let latestNum = latestNum, let currentNum = current?.num else { return false }
    return  latestNum != currentNum
}).distinctUntilChanged()

isPreviousEnabledはコミック番号が１かどうかを確認するだけですのでmapで適切なブールを返します。

isPreviousEnabled = currentComic.asDriver().map({ (comic) -> Bool in
    guard let num = comic?.num else {
        return false
    }
    return num > 1
}).distinctUntilChanged()

distinctUntilChangedは回覧中が変わる度にブールの値が変わらなければ無駄にenabledのバインディング処理が起こさないようにあります。

ビューモデルの初期化は以上で終わります。他の関数はapiサービスの呼び出しとビューモデルの情報の更新です。

ApiサービスもRx化になっているのでsubscribe(onNext:)でコミックの情報を取得します。情報はComicモデルクラスの形で来ますが、モデルから表示用に変えるのがupdateViewModelというヘルパー関数で行います。日付のフォーマットを変えたり画像のurlのstringをURLオブジェクトに変換します。

func getLatestComic() {
    service.getLatestComic().subscribe(onNext: { (comic) in
        guard let comic = comic else {
            return
        }
        self.latestComicNum.value = comic.num
        self.updateViewModel(comic: comic)
    }).disposed(by: disposeBag)
}

各Variableのvalueをアサインすると、Rxのバインディングで画面が更新されます。

private func updateViewModel(comic: Comic) {
    self.currentComic.value = comic
    self.title.value = comic.title ?? ""

    if let urlString = comic.img, let url = URL(string: urlString) {
        self.imageUrl.value = url
    }

    if let date = comic.date {
        self.date.value = formatter.string(from: date)
    } else {
        self.date.value = ""
    }
}

モデル

モデルは生のデータしか持ってないstructです。引数としてDictionaryを渡せるコンストラクタもありますが、基本的にはロジックが持ちません。ビジネスロジックはビューモデルか別のクラスに委任すると良いです。例えばコミックを取得するのはComicServiceの役割で、それを利用するのはモデルではなくビューモデルですね。

何かのロジックを入れるとしたら、内部のデータの形式の変更やデータのバリデーションぐらいなら良いかと思います。

TODO

エラーハンドリング

このサンプルコードは未完成なプロジェクトになっています。エラーハンドリングは行っていません。実装のアプローチとしてビューモデルからアラートを出すのは一番簡単ですが、エラーの場合にビューを更新したい場合はエラーの状態を持つ監視型のプロパティーをビューモデルに追加してビューコントローラーでバインディングしてビューを更新されるのが考えられますね。

テスト

テストコードも一切書いてないですね。書くとしたら主にビューモデルのテストを書いたらカバレッジの高いテストになります。ビューコントローラーにはロジックがなくて、ビューモデルにはテストの難しいビューもありませんのでテストが書きやすくなっています。

テストに関するもう一つ改善できるところはビューモデルが持つComicServiceのインスタンスです。現状のコードだとビューモデルでインスタンスを生成してますが、DI（依存性注入）を使ってインスタンスをビューモデルに渡すとテストのターゲットの際、テスト用のモックサービスに入れ替えて通信なし気楽にテストできるようになります。

それらの課題は今後、の記事の続きにしたいと思います。

参考

• [初心者]RxSwiftの道標[入門]
• 初めてのRxSwiftの発表資料

新卒2017の入社式をやりました

こんにちは、社長の中平です。

4月3日よりガラパゴスでは新たな仲間を4名を迎い入れました。

11時より社内会議室（ダーウィン）で執り行われた入社式では、 涙あり笑いありの非常に思い出に残る式となりました。

実は一ヶ月前の3月からインターンとして入ってもらっていたので、 入社式をしても新鮮味は無いかなと懸念していましたが、そんなことはありませんでした。

ワクワクキラキラとした彼らの目を見ていると、こっちもワクワクしてくるし、 彼らが輝ける場所をこれからも作り続けないとなと身が締まる思いです。

そして今日から2ヶ月間、地獄の(？)の研修が始まります。

優秀なエース級の先輩社員達が創意工夫して作ったデジタルモノづくりを骨の髄まで学べるスペシャル研修。 正直、羨ましいなと思いつつも、彼らがどのように成長していくのか、今から本当に楽しみです。

最後に、ガラパゴスは常に最先端の技術に寄り添う会社です。 その思いを知って欲しくて入社式で彼らに伝えた事。

• 　学び続けよう（好奇心を絶やさず、独自に学び、謙虚に）

• 　同期は宝

• 　視野を高く、志高く

2ヶ月後にまたブログ書こうかな！ 成長が本当に楽しみ！！！