| Mr.Hack | ||
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ◆目次◆ ■前回の解答
Mr.Hackです。 いかがお過ごしですか、Mr.HackはSpring semester(春期学期）のFinal(期末試験）の勉強で四苦八苦しています。皆さんはゴールデン・ゴールデンの後に五月病にならないようにがんばっていきましょう。 さっそく、宿題の解答からいってみましょう。 ■前回の解答 Question 5 の答え 【BankAccountTest.java】 前回は、BankAccount.classファイルと、そのクラスのAPI仕様をBankAccount.zipとしてダウンロードしてもらい、APIをみてBankAccount.classをテストするという内容でした。まだダウンロードされていない方は、 http://mrhack.hoops.ne.jp/zip/BankAccount.zip からダウンロードして、BankAccount.classを自分で作った、BankAccountTest.javaと同じフォルダにおいてBankAccountTest.javaをコンパイル・実行してください。上記の解答のBankAccountTest.javaを実行すると ------------------------------------------------------------------------ withdraw()テスト getBlance()テスト となります。前回はtry&catch構文を習いましたが、それを少し応用して各BankAccountクラスのメソッドをテストしてみました。最初のtry&catch構文を見てみましょう。BankAccountクラスのインスタンスを初期化（残高ゼロ）した後、 BankAccount account = new BankAccount(); テストとして、deposit()メソッドに-1をアーギュメント（実引数）として渡します。APIを見ると、 ------------------------------------------------------------------------ amountがマイナスの場合はException classの例外が発生すると書いてあるので、APIのクライアント(client)であるBankAccountTestクラス側では、その発生した例外をキャッチしてあげなければなりません。テストでは、わざと-1で例外を発生させようとしているので、期待しているプログラムの流れは、 ------------------------------------------------------------------------ で例外が発生し、catch節に流れが移り、 ------------------------------------------------------------------------ が実行されます。例外が発生したときは、次の文である、 ------------------------------------------------------------------------ は実行されません。逆に、例外が思ったように（期待したように）例外が発生しなければ、すぐaccount.deposit(-1)に続き”マイナス引数テスト失敗”が実行され、catch節は実行されません。つまり、try&catch構文をうまく利用することによって、メソッドである、deposit()をテストすることができるのです。 それに続く各try&catch構文は基本的に同じ考えで同じことをしています。それでは、例外を発生させないgetBlance()はどうやってテストするのでしょうか？ getBlace()メソッドは戻り値としてdoubleを返します。そのため、戻ってきた実際の値が、論理上期待される値と同じかどうかを比較し違っていれば”テスト失敗”、同じであれば、”テスト成功”というメッセージをプリントすれば、良さそうです。 ------------------------------------------------------------------------ accountの参照変数を新しくnew BankAccount()作られた新しいオブジェクトを参照し直します。つまり、残高はゼロになります。その後期待値である1000円を入金します。すると、そのBankAccountクラスのオブジェクトの残高は、論理上は、1000円になります。そして、getBlance()メソッドを使えば、論理上は、1000.00というdouble値が戻ってくるはず、です。その実際の戻ってきた実際値と期待値をif文を使って比較します。同じなら”テスト成功”、違うなら"
皆さんの中には、何で地道なテストなんてしないといけないの？それよりも、コマンドベースのソフトのような、ちゃんとメニューがあって、メニューを選ぶと預金や引出をするようにしたい、と思っている方もいらっしゃるでしょう。または、JSPやServletなる技術を早くつかってサイト構築をしてみたい、と思っている方もいるでしょう。そう思っている方からすれば、テストなんて、ホント苦痛でしかないことかもしれません。それより新しい技術であるJSP, Servletを体験してみたい、と思うかもしれません。 気持ちは、分かります。でも、もう少しお待ち下さい。はやる気持ちを抑えて、もう少しテストの仕方をじっくり学びましょう。これが、必ず、あなたのプログラム技術を向上してくれます。デバッグによるバグ発見までの時間を大幅に短縮してくれます。 ユニットテスト（単体テスト）とは、どういうものなのでしょうか？ 伝言ゲームを想像してください。ＡさんがＢさんに”Mr.Hack”と言いました。ＢさんはＣさんに同じことをいいます。ＣさんはＤさんに、ＤさんはＥさんに、と伝言していきます。最後にＺさんに伝言は何ですか？と聞くと”Mr.Maric”と答えました。伝言失敗です。Ｚさんはどこで、誰が間違えたか、分かりません。どうやって原因を確かめますか？Ｚさんは最初に、ＹさんにＸさんはなんと言いましたかと聞きます。Ｘさんは”Mr.Hack”です、と答えてくれれば、ビンゴ！原因究明です。Ｙさんが間違えたのです。しかし、Ｘさんにきいても、ＷもＶさんもMr.Maricと答えたらどうしましょう？さて困りました。Ｚさんは、アルファベットの逆順にひとりづつ聞いていくのが効率がいいでしょうか？それとも、真ん中あたりの、Ｌさんに聞くのがいいでしょうか？それとも、Ａさんに？・・・。 この伝言ゲームなら最高でも２５回（Ｘさんに１回と数えれば、Ｗさんが２回・・・Ａさんが２５回目）聞けば、原因を確かめられます。しかし、実際のプログラムだと、ＡさんからＧさんにいきなり飛んだり、ＧさんがまたＡさんに伝言を戻したりと、複雑な関係の上に成り立っています。 そこで登場するのがユニットテストです。まず、ＡさんがＢさんに”Mr.Hack”とちゃんと言ったかを伝言時にテストします。確かに”Mr.Hack”と言いました。Ｂさんは、Ｃさんに”Mr.Hack”といったか伝言時にテストします。このようにして、全てのアルファベットを伝言時にテストしていきます。Ｇでテストすると、”Mr.Maric”と伝言していました。このように伝言時点で、一つのアルファベットをテストすることをユニットテスト（Javaではクラス、classがユニットにあたる)といいます。このように全てテストしておけば、事前にどこで間違えたかを確認でき、最終的にはＺは正しい伝言を受けたと確認できます。後者のＧで間違いだと分かったのはクラス単位でテストした段階での発見といえます。上記のＺさんが伝言を受け取った時に間違いだと分かるのは、実際のプログラムで言えば、プログラムが完成し実際施行テストする段階での発見といえるでしょう。どちらが効率いいでしょう？クラスが２、３ぐらいしかない場合はあまり、ユニットテストのありがたみを味わえないかもしれませんが、これが、２０も３０も、はたまた、１００クラスを超えたときのことを想像すると、原因究明に多大な時間を浪費するだろうことが容易に想像できます。 ところで、余談ですが、ソフトウェア工学にXP（eXtreme Programming、WindowsXPではない)と言うプログラミングスタイルがあります。そのスタイルの一つに、プログラムを書く前に、テストプログラムを書き、その期待しているテストに沿ったプログラムを書けば、エラーが起こらないという考え方があります。ちゃんとしたテストプログラムを書いて、それを満たすメソッドであれば、たしかにそのクラスはちゃんと作動しますね。この条件ではマイナスはダメというテストプログラムを書きテストメソッドがマイナスを出さないようにするまで、プログラムを書き直します。伝言ゲームで言えば、ＦさんがＧさんに”Mr.Hack"と言わなければ、言うまでＦさんをテストします。Ｆさんが”Mr.Hack”と発音出来なければ、発音の強制をします。発声練習をさせます。そしてＦさんが”Mr.Hack”と伝言出来るようになれば、やっと次の段階に移ります。 でも、この考え方は、初心者の方にはとても、難しいのです。なぜなら、テストプログラムをつくっても、テストの対象になるクラスが存在しないと、テストプログラムを実行できないからです。Ｆさんの発声練習にはＦさんが実際いないと出来ないのと同じです。前回の宿題でも、BankAccount.classファイルがないと、BankAccountTest.javaをコンパイル実行できませんね。 ためしに、BankAccount.classを削除するなり、他のフォルダに移すなりして、コンパイルしてみてください。テストの対象であるBankAccount.classがないので、もちろんコンパイル・実行はできません。 銀行口座を実現するクラスBankAccount.javaを作れといわれたときに、ふつうは、メンバフィールド（変数）やそのメンバフィールドにアクセスするメンバメソッド（メソッド）を考え、メソッドが戻り値を返すか返さないか、返すなら、どのデータ型かを考え、そして、メソッドの中身を考えますね。そしてメソッドに戻り値があるなら、ちゃんと望みの値を返すかどうかをチェックします。 しかし、XPでは、はじめに、銀行口座に必要なメンバ（変数・メソッド）を考えて、そのメソッドをテストするプログラム（BankAccountTest.java)を書きます。そして、テストプログラムで”テスト成功”となるように各メソッドのするべきことを決めるのです。これが、XPでいわれている実際のコードを書く前にテストプログラムを書くということなのです。 XPで言われているようにまで、皆さんは徹底する必要はないと思いますが、クラスを書いたらテストする、この習慣をぜひ身につけたいですね。 それでは実際に、BankAccount.javaのクラスを作って実感してみましょう。 ■BankAccount.java BankAccount.javaを書くにあたって、もう一度、クラスを確認します。クラスとはオブジェクトを作るに当たっての仕様書・設計図でしたね。たい焼きの例を思い出してください。たい焼きの例では、たい焼きにはあんこがありますね。たい焼きにあんこ（メンバフィールド、変数）を含めるということをクラス仕様書で定義してあげました。銀行口座というクラス仕様書を作るに当たって、どんなメンバーフィールドが必要ですか？もし、総合口座にすれば、 口座番号 等いろいろと考えられますね。この場合、例えば、 class BankAccount { のようになります。物事を簡潔にするために、BankAccount.javaクラスは、balanceフィールドだけ持つようにしましょう。つまり、定期預金、普通預金区別なく、単に残高一つだけ存在するだけにします。また、口座番号、預金者氏名等も省略します。 class BankAccount { これで、BankAccountクラス仕様書にしたがって作られたオブジェクトには全て、balanceフィールドが含まれますね。たい焼きのあんこのように。 ところで、なぜint型でななくて、double型なのでしょう。お金の単位は1円からですね。１円が実際の日本社会でやりとりされる最小単位です。１００円なら、100でいいですね。しかしながら、論理上は”銭”という単位が存在します。たとえば、為替相場を見てください。1ドルが130円56銭になります。実際銭という単位でお金をやりとりはできず、切り上げ・切り下げして扱われます。しかしながら、ドルを円に換算して、銭を切り下げして、引き出すにしても、銭という単位まで考えるか否かによって、実際の手元にくるお金はかなり変わってきます。たとえば、為替相場で、１ドル130円56銭ではなく、130円ならどうでしょう。もし１０００ドルを円に換えると、1000 x 130 = 130,000円ですが、銭単位まで考えると、130,560円になり、５６０円も変わってきますね。そのため、銭単位まで考える必要は未だにあるとおもいます。あるいは、ビジネスルールとして、為替相場で銭単位の端数がでるにしろ切り捨て、切り捨てた後、その切り捨てた円を口座に預金する、とするのであれば、balanceはint型でもいいと思います。 オブジェクトを作るときに、初期化が必要になりますが、初期化の働きをになうのが、コンストラクタです。初期化するとは、この場合、どういう意味なのでしょう。口座預金の場合は、新しく口座を作る（BankAccountのインスタンスを作 // コンストラクタ。初期化時残高をゼロにセット これで、初期化（Instantiate）するときに残高はゼロにセットされます。また、はじめて預金口座を開設したときに、ついでにお金も預金したい人もいるでしょう。そのために、パラメータ付きのコンストラクタも作りましょう。 // コンストラクタ。初期化時残高をamount分セット BankAccount(double amount)のコンストラクタを作ると、balanceをゼロとセットするデフォルトのBankAccount()コンストラクタもBankAccount(double amount)の一部と見ることができます。つまり、thisキーワードをつかって、デフォルトコンストラクタは // コンストラクタ。初期化時残高をゼロにセット とすることができます。カッコ付きのthisキーワードは、コンストラクタを表します。初期化しようとしているインスタンスの、パラメータがdoubleである”この（BankAccount(double amount))”コンストラクタを使い、ゼロで初期化するということです。 初期化をしてBankAccountクラスのインスタンスを作った後に、口座開設者は預金をしますね。そのため、預金するためのメソッドが必要になります。預金するためのメソッドをdeposit(預金する）としましょう。depositするためには預金するお金(amount）が必要なので、そのお金をパラメータとして、 // amount分のお金を預金する というようになります。プリミティブ型（ここでは、double型）のときは、"="（イコール）は代入を意味します。つまり、いままでの残高（balance)に新しく預金するamountを足してその合計(balance + amount)を新たに、balance変数に代入します。もしここで、 balance = amount; としたら、どうなりますか？これは、amountをそのまま、balanceに代入する(上書きする）ことを意味しますね。残高が0.0円の時は問題ないです。しかし、もし、前に残高があったらどうしましょう？例えば、すでに、100.00円という残高をbalance変数が保持していて、預金額500.00円をamountとしてdeposit（預金）するとどうなりますか？そう、100.00という値が、500.00という値で上書きされてしまいますね。そのため、balance + amountという形が必要なのです。 balance = balance + amount; は blance += amount; と同じことを意味します。初心者の方は、この形になれるまで結構苦労なさると思いますが、プログラミングではよく使うスタイルなので、がんばってなれてみてください。 銀行口座から、ある金額（amount）を預金したら、引き出すメソッドが必要ですね。引き出すメソッドをwithdraw（引き出す）としましょう。引き出すときにいくら引き出すか問題なので、amount(お金）のパラメータが必要ですね。withdraw()メソッドは下記のようになります。 // amount分の金額を引き出す。amount分をbalanceから引く ここでは、-=がでてきましたね。これは、+=と同じスタイルで、 balance = balance - amount; と同じ意味です。 さて、最後に、現在の残高を得るメソッドを作りましょう。そのメソッドをgetBlanceとし、戻り値は、現在の残高を返すようにしてみましょう。現在の残高を返すには、 // 残高を返却 となります。BankAccountクラスのメンバフィールドであるbalance変数が保持している値を返します。 ここまでの完成classが下記です。 【BankAccount.java】 /** /** /** /** /** BankAccount.javaがあるフォルダに、Question 5の解答のBankAccountTest.javaがあることを確認（前回ダウンロードしたBankAccount.classはどこか違うフォルダに移してください。そうしないとコンパイル時に、上書きされます）し、コンパイル実行してみてください。コンパイルエラーはでませんが、実行すると、 ------------------------------------------------------------------------ withdraw()テスト getBlance()テスト となり、getBlance()テストは成功していますが、deposit()テストとwithdraw()テストは失敗です。何故でしょう？原因を探ってみましょう。 BankAccountTest.javaクラスを見てください。deposit()メソッドとwithdraw()メソッドはそれぞれ、try&catch構文を使って例外が発生すれば”テスト成功”、発生しなければ、通常処理で”テスト失敗”になりました。というのは、-1や0等は本来、預金金額や引出金額として望まれない値ですから、クライアントであるBankAcount.classでdeposit()メソッドやwithdraw()メソッドを使った（呼び出した）ときに例外が発生したのですね。それをチェックして、テストが成功したか否かをチェック（プリントアウト）したのです。つまり、上記のBankAccount.javaでは-1や0等をパラメータとして受け取っても、例外を発生させられなかったのですね。だから、BankAccountクラスのクライアントであるBankAccountTestクラスは例外をキャッチできず、通常の処理（例えば、account.deposit(-1)のあと、catch節に移らずに、System.out.println()メソッドで、”テスト成功”をプリントアウト）をしたわけです。 では、どうやって、例外を発生させることができるのでしょうか？ 引き続き、後編をお楽しみ下さい。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ |
||
| © 2002 MR.HACK ALL RIGHTS RESERVED | ||