Deletions are marked like this. | Additions are marked like this. |
Line 35: | Line 35: |
方策は二つある。 * ADTプラグインを使わない。プロジェクトを普通のJavaプロジェクトとする。 * ADTプラグインを使うが、そのapkビルド機能は使わない。 しかし、いずれにしてもantは利用しなければならないので、結局前者の方が楽ではある。 次はbuild.xmlをどこからか調達することが課題である。 |
テスト環境について
Androidには立派なテスト環境があり、「これだけやっとけば大丈夫だろ」と言わんばかりのものらしいが、これは間違い! 。。。いや間違いではないのだが、主軸にしてはならない。
Eclipseを開発環境とするならば、Eclipse上でささっとテストができるべきである。 これがまず第一。その上で、テストしにくいGUI部分をこの環境で行うのなら完璧というところだろう。
わざわざテスト用のアプリを作成し、それを決して速いとは言えないエミュレータにインストールし、それからもろもろのテスト操作を行うというのでは、 嫌になること請け合いである。
テストは楽しくなければならないのである。
GUIとビジネスロジックを分割する
Android云々、テスト環境云々以前に、まずこの技術を習得しなければならない。 そもそもGUIは、どういう方法をとってもテストしにくいものなのだから、GUIコードとビジネスロジックコードが完全に分割できるように しなければならない。
「Androidのテスト環境」にいくら習熟しようともこの点を習得することはできない。
世にあるあまたのサンプルプログラムは、この点を無視したものが非常に多い。 そこを認識しているか認識していないかの違いで、技術者としての力量がわかるものである。
ADTプラグインを何とかする
Eclipse上のADTプラグインは便利なものだが、一つ困ったことがある。 プロジェクトの実行に必要なものを有無をいわさず取り込んでapkにしてしまうことである。
これがなぜ困るのかと言えば、安易にテスト用のコードを混ぜることができないから。 これがゆえにAndroid「純正」のテストは、わざわざ別プロジェクトを作成することになっている。
この環境は、同じプロジェクトにテスト用コードがあるなどとは夢にも思っていないのである。 これでは(私のやり方としては)困るのである。
方策は二つある。
- ADTプラグインを使わない。プロジェクトを普通のJavaプロジェクトとする。
- ADTプラグインを使うが、そのapkビルド機能は使わない。
しかし、いずれにしてもantは利用しなければならないので、結局前者の方が楽ではある。
次はbuild.xmlをどこからか調達することが課題である。