B-Teck!

お仕事からゲームまで幅広く

【ゲーム】インファマス セカンドサン

『Ghost of Tsushima(ゴースト オブ ツシマ)』でも最近話題となっているサッカーパンチ。
好きな人にとってはスライ・クーパーの方が代表作かも知れないが…。
今回はそのサッカーパンチが以前開発したこのゲームを紹介していく。

インファマスシリーズ3作目の本作は、超能力を得た主人公がオープンワールドで暴れまわる作品。
過去作の設定の延長上の物語が描かれるものの、キャラクターや舞台は一新。
今作から遊び始めても問題ないストーリーとなっている。
プレイ時間は2~30時間程度。トロフィーを取りながらゆったり破ってもそのくらいで終わると思う。

選ぶのは、正義か、悪か

f:id:beatdjam:20180428020200j:plain 自らの選択で、後ろの女の子を更生に向かわせることも、堕落させることもできる。

インファマスシリーズ3作目である今作も、
前2作と同様に善ルートと悪ルートのストーリーが存在する。
得た力を人々を守るため、何かを助けるために使うルート、
圧倒的な力で周囲をねじ伏せ、自分の力を誇示するルート。
大筋のストーリーでは大きな違いは無いものの、ミッション中のセリフや進行などが変化する。
特に面白いのが市民の存在で、善人でいればそこかしこで称賛と応援の言葉を聞くことができる。
反面悪人ルートの場合、誰からも蔑まれ、罵倒され、どこにも味方はいない。

何の力を振るうのか

f:id:beatdjam:20180428020710j:plain 作中では4つの能力を使うことができる

最初に入手する、煙を操る能力。
光となって街中を駆け回る能力。
ゲームの世界に入り込んで、天使や悪魔、巨大な武器を召喚して戦う能力。
そして、コンクリートを扱う能力。
主人公はストーリーが進むごとに新たな能力を得ていく。
本編での活躍が少なく、クリア後に使える程度といった能力もあるが、
それぞれの能力で異なったプレイ感や別の戦略がある。

箱庭としてのシアトル

f:id:beatdjam:20180428021704j:plain f:id:beatdjam:20180428021713j:plain 夕暮れのシアトルと、スペース・ニードルをバックに

オープンワールドとはいうものの、フィールドに存在するミッションは単調で、
徘徊する市民にパーソナリティはない。
あくまでプレイヤーが主人公の能力を好きに使って暴れられるように作った箱庭という感じ。
小粒感のある本作ではむしろそれが良い要素として効いており、
縦横無尽に飛び回って戦っている感覚を味わえる。

感想

操作性、ボリューム感、ストーリー全てで爽快感に重点を置いた作りになっている本作。
サクッとプレイできることもあり、プレイ時間での満足度は大きめ。

クリア後に進行度を100%にしてしまうとほぼやることがなく、
かといって最高難易度がそこまで難しくない。
やりこみユーザーにはおすすめできない。

ストーリーは善ルートのほうが好き…だし自然だったように思う。
悪ルートはいまいち気持ち的に乗り切れず…残念。

もし安くなっていたりしたら買ってプレイする価値はあるゲームだと思う。

【本】JUnit実践入門 体系的に学ぶユニットテストの技法を読んだ

JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)

JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)

本書は、全15章のトピックを5つのPartに分けて解説している。
Partごとに自分が重要だと思ったトピックを抜き出して読書メモとしてまとめた。

Part 1 JUnit入門

ユニットテストとは?

ユニットテストは、自分の書いたコードに責任を持ち、変更に強いプログラムを書く手法である。
あるプログラムが想定通りの振る舞いをするかテストするプログラムを書くことで、
その仕様を明確にし、変更や改善を継続的に行っていける仕組みを作ることができる。
想定する振る舞いがプログラムとして記述されているので、テストコードはそれ自体が仕様書のようなものになる。

ユニットテストに求められるパターン

実行順や状態に依存せず、単体で繰り返し実行できるテスト
振る舞いをわかりやすく記述し、問題発生時にはその特定が容易になるようなテスト

良いテストコードとは?

前提条件、入力値とその操作、期待値が必要十分であること
一つのケースで複数のテストを行っていないこと

テストしやすいコード

戻り値を持ち、副作用がなく、同じ入力に対して常に同じ結果を返す関数的メソッドがよりテストしやすい
ユニットテストを意識することでテストしやすいコードを書くことができる

JUnit4の代表的なアノテーション

  • @Test:テストコードの宣言(expectedで例外のテスト、timeoutで実行時間のタイムアウトを設定するなどできる)
  • @Ignore/実装中などものをテストの実行から除外する
  • @Before/テストクラス内の各メソッドを実行する前に行う初期化処理
  • @After/テストクラス内の各メソッドを実行後に行う終了処理
  • @BeforeClass/テストクラス内の最初のテストメソッドを実行する前に行う初期化処理
  • @AfterClass/テストクラス内の最後のテストメソッドを実行後に行う初期化処理

ユニットテストの基本パターン

  • 標準的な振る舞いのテスト(4フェーズテスト)
    • 事前準備/オブジェクトの初期化や前提条件の設定
    • 実行/処理の実行
    • 検証/処理結果の確認
    • 後処理/場合によっては次のテストに影響が出ないような処理が必要
  • 例外の送出テスト
  • コンストラクタの生成テスト

Part 2 第2部 JUnitの機能と拡張

Matcher

JUnitではMatcherという仕組みでテスト結果の検証を行っている。
標準で実装されている代表的なMatcherメソッドは下記

  • CoreMatchers

    • is/期待値と結果をequalsで比較する
    • nullValue/nullであることを検証する
    • not/引数のMatcherの結果を反転させる
    • notNullValue/nullでないことを検証する
    • sameInstance/期待値と結果が同じインスタンスであることを検証する
    • instanceOf/結果が期待値するクラスのインスタンスであることを検証する
  • JUnitMatchers

    • hasItem/リストや配列などに期待値が含まれている
    • hasItems/リストや配列などに複数の期待値が含まれている

その他にも、自分でカスタムしたMatcherを定義することができる

テストランナー

JUnitでは、テスト実行対象のカスタマイズのために、テストランナーという仕組みを用意している。
標準では下記が用意されている

  • JUnit4/テストクラスの中の有効な全テストケースを実行する
  • Suite/複数のテストクラスをまとめて、有効な全テストケースを実行する
  • Enclosed/同じ初期化を行うテストケース等をまとめて構造化したテストクラスを実行する
  • Theories/@DataPointと組み合わせて、テストメソッドとパラメータを分離したパラメータ化テストを実行する
  • Categories/テストクラスをまとめてカテゴリ化し、特定のカテゴリのテストを実行する

テストのコンテキスト

テストケースが増え、テストクラスが大きくなってくると可読性が下がるので、構造化による分割を行う必要がある。
テストクラスの構造化にはテストランナーのEnclosedが便利。
同じコンテキスト(テストに関連する前提条件や状態、操作やデータ等)の単位で分割しまとめる。

  • 同じメソッドをテストする単位
  • 同じ前提条件や初期化、後処理を行う単位

テストフィクスチャ

4フェーズテストの事前準備に該当する部分。テストの前提条件となる操作や状態をフィクスチャと呼ぶ。
フィクスチャをテストケースごとに独立させ、都度生成するフレッシュフィクスチャという考え方が基本。

ユニットテストのフィクスチャは主に下記のような要素

  • テスト対象オブジェクト
  • 実行に必要なオブジェクト(入力値)
  • 検証に必要なオブジェクト(期待値)
  • テストに必要なオブジェクト操作
  • テストで扱う外部リソース
  • テストで扱う外部システム
  • モックオブジェクト

フィクスチャのセットアップを行うパターンは下記

  • インラインセットアップ/テストメソッド内でフィクスチャのセットアップ
  • 暗黙的セットアップ/@Beforeで抽出した初期化処理を用いたセットアップ
  • 生成メソッドでのセットアップ/生成メソッドを作成し、セットアップ済みのフィクスチャを生成させる
  • 外部リソースからのセットアップ/外部リソースに内容を定義し、読み込んでセットアップ

パラメータ化テスト

入力値と期待値をテストメソッドから分離して定義し、パラメータとして利用する手法。
@Theories、@DataPoint(s)を利用して組み合わせを網羅したテストを実施する。
対象外のパラメータの組み合わせについては、Assumeクラスを用いて除外することができる

ルール

ユニットテストの拡張機能を適用する仕組み。テストケース実行ごとに適用・実行される。
JUnit標準で用意されるルールの他、TestRuleインターフェースの実装をすることでカスタムルールを作成できる。

標準で用意されているルール

  • TemporaryFolder/テスト実行時に一時フォルダを作成し、終了時に破棄する
  • ExternalResource/テスト実行時に外部リソースを準備し、終了時に破棄する
  • Verifire/テスト終了後の状態を検証する
  • ErrorCollector/エラーが発生してもテストを継続し、全てのテストを実行する
  • ExpectedException/例外オブジェクトに対して詳細なテストが必要な場合にその詳細を扱うことができる。
  • Timeout/テストのタイムアウトを設定する
  • TestWatcher/テスト実行を監視し、実行中に処理をインタラプトさせることができる
  • TestName/実行中のテスト名称を取得する

クラスルール

@ClassRuleを用いるとクラス単位でのRuleの適用を行うことができる。
BeforeClassやAfterClassで行ったような操作をルールとして記述する仕組み。

カテゴリ化テスト

スローテスト問題

ユニットテストを実施していくと、次第にテストの実行速度が遅くなってくる。
ユニットテストのサイクルが遅くなることで、有効ではなくなってしまうことがある。
その原因は主に下記の3つ

  • データベーステスト
  • 通信処理を伴うテスト
  • GUI操作を伴うテスト

その対策は主に下記の4つ

  • 最適化により実行時間を短くする
  • 実行環境の強化
  • テストの並列実行
  • テスト対象の絞込み

テスト対象の絞込みを行う仕組みのカテゴリ化テスト

テストクラスをカテゴリに分割し、目的に応じたテストを任意のタイミングで行う手法。
スローテスト問題を起こしやすい箇所をカテゴリ分けすることで普段は除外してテストを行ったりできる。

Part 3 ユニットテストの活用と実践

テスタビリティ

  • テスタビリティの高いテスト対象とは

    • 複雑な状態を持たない
    • 多くの引数を持たない
    • 単一の目的を処理している
  • テスタビリティを高めるにはリファクタリング

    • メソッドの抽出
    • 移譲オブジェクトの抽出

テストダブル

テスト対象の依存するクラスを置き換える代役オブジェクト。
依存するオブジェクトの振る舞いを固定したり、呼び出しを検証する際に用いる。

よく利用されるのは下記の三種類

  • スタブ
    依存するクラスやモジュールの代用となるオブジェクト
    不安定なテストケースを検証可能な形とすることを目的にしている
  • モック
    依存するクラスやモジュールの代用となるオブジェクト
    依存先モジュール等を正しく呼び出しているかの検証を目的にしている
  • スパイ
    依存オブジェクトの呼び出しを記録・監視するために、オリジナルのオブジェクトをラップしたオブジェクト
    副作用のあるテストケースなどで結果を確認するために用いる

カバレッジ

カバレッジとは、ユニットテスト実行時のプロダクションコードの実行割合。
実装済みのロジックを検証するものであり、仕様自体を保証するものではない。
常時測定し、一定の割合を維持することで品質を保つ指標とできる。

コードカバレッジの基準は下記(ただしC2はほぼ用いられない)

  • C0(命令網羅)/命令が実行された割合
  • C1(分岐網羅)/分岐が実行された割合
  • C2(条件網羅)/真偽条件の組み合わせが実行された割合

Part 4 開発プロセスの改善

継続的テストとは?

バージョン管理システムの変更等をトリガーに自動的にテストを実行する手法。
早期から自動で繰り返しテストされるため、フィードバックからの改善を行いやすい。
継続的テストを行うには、バージョン管理、自動化、ユニットテストの導入が必要。
Maven等のビルドツールを用いる場合や、Jenkins等のCIツールを用いる場合もある。

テスト駆動開発(TDD)/振舞駆動開発(BDD)

テスト駆動開発とは?

テストファーストで開発することを原則とした開発手法。
先にテストを書くことで仕様を明確にしながら実装を進めることができる。
テストを意識した設計になるので見通しがよくなりやすい。

振舞駆動開発とは?

ソフトウェアがどのように振る舞うかをシナリオとして定義してテストを行う手法。
TDDよりも大きい粒度で、外部から見た機能や期待される仕様を定義する。

Part 5 演習問題(演習問題のため割愛)

感想

良かった点悪かった点それぞれあるものの、総合的に読んで良かった本だった。
悪かった点も発売時期を考えれば仕方のないといったところで、内容についてはほぼ不満はない。
少し古い情報の本なので手放しには勧められないものの、ユニットテストについて知りたいという人には勧められる本。

  • 良かった点
    JUnitの使い方の解説にとどまらず、一般的なテストの技法や用語の解説、
    なぜこの機能が使われるのかという解説を含んでいるので、初学者でも一通りの知識を得ることができる。
    実践入門の名前にふさわしく、ユニットテスト導入時に最初に読む一冊として必要な内容を網羅している印象。

  • 悪かった点 この本が書かれたのが2012年のため、扱われているプラグイン等は現在は更新が止まっているものや、
    もう使われていないものなども含まれている点が難点。
    最新の事情に合わせると、実践は自分で調べながらの部分が多少出てくることになると思う。

【本】じゃんけんしようよを読んだ

じゃんけんしようよ

じゃんけんしようよ

相変わらず、KDPの十千しゃなおさんの小説をちょいちょい読んでます。
今回のじゃんけんしようよは、実は文庫本二冊くらいの結構な長編だったので、
まとまった時間が取れたら読もうと思いながら数年積んでいました。
やっと一通り読み終わったので感想を書いているんですけど、
よくよく見ると続きとか関連書籍があと3冊位あるんですよね。
またゆっくり読んでいこうと思います。
さて、以下感想です。

じゃんけんなのに、スポ根?

正直、じゃんけんしようよというタイトルで何が描かれているのか、
読む前はあんまり想像できてなかったです。
読みはじめて見て驚いたのが、じゃんけんが普通にスポーツだったことです。
じゃんけんの大会が夏の甲子園のような扱いであったり、じゃんけんの大会で負傷者が出たり、
部活動でサンドバッグを殴っていたり…
一般的に想像される「じゃんけん」とはだいぶずれた世界がそこに広がっていました。
でも、途中にはじゃんけんならではの展開もあり、そうでないものもあり…
読み進めるうちに何故かじゃんけんは普通に競技だと思えてしまうんですよね。
そんなパワーがありました。

長編・王道でも変わらない十千しゃなおらしさ

これは、こんな風に書くのも失礼かなと思うんですけど、
十千さんの体育会系のスポ根、ライバルの登場、成長物語、
みたいな王道の話を読んだことがなかったのでどうなるのかなと思ってました。
でもそんな不安を吹き飛ばすような、相変わらずテンポの良い会話と展開、
読みやすい文体でサクサク読み進められました。
ちょいちょいある誤字脱字と、登場人物の難読さも含めて、ご愛嬌というか、安心感がありました。
ただ、変わらない読みやすさながら、いつもの短編的な作品と違って、
しっかりとしたお話が描かれていた印象です。

設定の消化不良感

前二点で良かった点を書いたので、一つだけ気になった点を。
この小説は本来数冊のシリーズで描かれるはずだった内容をまとめているという経緯があるようです。
そのためか、しっかりとしたキャラを持ちながらもあまり描写されずに流されてしまうキャラクターや、
比較的大きな展開だと個人的に思っていた場面であっさり地の文で物語が進んでしまうなど、
駆け足の部分があるのは否めません。
とはいえ、しっかりと描くべき部分は山場として描かれているのでそう不満もないのですが…

というわけで、一風変わった題材の作品でしたが、とてもおもしろかったです。
値段も安いので、もし興味があれば読んでみてください。