品質を担保するためのアーキテクチャー

品質とアーキテクチャーは非常に密接な関係があります、でも世の中はそんなこと考える人は非常に少ないのも事実だったりします。しかし正しいアーキテクチャーでソフトウェアを組めば、開発後半戦で多量のバグが発生し、製品もメンバーの心もボロボロにならないですし、健全に開発計画をまっとうできます。

悪いアーキテクチャー

ユーザインターフェースや、様々な入出力のがプログラムのあちこちにちらばっており、いったいどこをテストすればソフトウェアの品質保証ができるかがわからないインターフェースです。

いいアーキテクチャー・インターフェース

いいアーキテクチャーとはユーザとのインターフェースが独立しています、これはテストの観点としての言い分ですが、ユーザインターフェースが独立していれば、そこに対して集中的なin/outのテスト実行が可能です。まあテストの本質はいかにin/outをちゃんと網羅できるかが80%だと思ってます。そこが無限だったりするので、組み合わせテストが必要だったり、その削減手法(all-pairとか)があったりします。でもそこを自動化したらどうでしょうか?機械に24時間in/outをずっとテストさせれば組み合わせテスト削減もいらず、ばんばんバグが出ると思いませんか?

さてさてどうやってソースコード実装するか

この手のソース実装は昔は結構メンドウだった。技術的にメンドウという意味ではなく、強力なアーキテクトがそのプロジェクトを引っ張って行く必要があった。まずGo4(今は死語?ググってみてください、若手の方は)のデザイン・パターン(http://amzn.asia/d/4MqtcHn)を読ませ、理解させそして実装を手取り足取りヘルプしなきゃならなかった。今はWidnowsでもAndroidでもそのフレームワークが充実してきたので、「みんなでこのフレームワークつかいましょうね」って言うだけで皆納得する時代になりつつある。概念はちょっとむずかしいが一度フレームワークを作ってしまえば、あとは結構コピペの世界なので慣れてしまえば手放すことができないフレームワーク。ちょっと覚えるのはメンドウ、なんかググってもいいのが出てこない。でも個人的にはこのYouTubeの教え方がよく理解できた(https://www.youtube.com/watch?v=KWjF4_kpIkU)

テスターが理解できる簡単開発ソースコード

上記のYouTubeのソースはちょっと冗長だったので、簡単な形で書いてみました。いろいろMVVM(Model View View Model)のソースをググってみましたがテスト担当者が簡単に理解できるようなソースは見つからなかったので、ちょっと自分でいじってみたので参考にしてみてください。
public void setEmail(String email) {
this.email = email;
Log.d(“view_mode”, this.email);
上記のコードがあるので、emailエディットボックスになにか入れるとview modelにその値が反映されるのがlog.dで見れます。

自動化用テストコード

さてそれでは自動化テストコードはどう書くのでしょうか?2つの方法が考えられます、1つは開発者テストっぽくスタブ/ドライバー(モック)を書いて行う方法。この方法がベストかもしれませんが、日本でちゃんとこの方法で実装している例をみたことありません。たぶんgoogle, facebookとかではやってると思いますが。もう1つはシステムテスト的アプローチです、かなり現実的なアプローチです。普通の自動化ならUIレイヤーから叩くのですが、View Modelレイヤからテストケースを叩きます。これならUIの変更に左右されにくいです。ただある機能をテストするためには、そこまでたどり着くテストケースを書かないといけないのは既存のテストと同様です。まあアプリや開発スタイルによってここをどう自動化実装するかはcase by caseになるかと。