arai

バグ管理、プロジェクト管理

先週の出来事です。


今回の案件は、Seasar2を利用したアジャイルの開発で、バグ管理、プロジェクト管理も含めてTracを使用しています。私も自宅でTracを試してみました。

Tracを調べてみるとTracはオープンソースで、Pythonで作成されています。Trac以外にもオープンソースで、開発されたバグ管理、プロジェクト管理が多数存在しているようです。言語別に代表作があるようです。


・Perl
Bugzilla

・PHP
Mantis

・Python
Trac

・Ruby on Rails
Redmine


Redmineは、Ruby on Railsで開発されたこともありバグ管理、プロジェクト管理では比較的新しく、最近注目されているようです。

昼食時にお客さんに話すと使ったことがないようなので、雑談ですが少しはお客さんに役立つことができました。

何でも調べてみると何かの役に立つこともあるですね。



話は変わりますが、引き続き常駐に関連した内容です。

Windows 7 + 64bit で Seasar2 を使うの記事で、Eclipseのメモリ使用量が高いと書きました。具体的な数値を書いていませんでしたが、多いときには300MBを超えています。

JavaでフレームワークをStrutsで使用したときは、通常、70MBで、多くても100MBから130MBです。そして、しばらくすれば、ガベージコレクションが動き、また70MBに戻ります。

現在の案件は、JavaでフレームワークにSeasar2、それ以外にも他のフレームワークを組み合わせていますが、それでも300MBは異常です。その原因は分からなかったのですが、先週途中からメモリ圧迫の減少は直りました。

先輩の記事にSeasar2か他のフレームワークの問題点が書かれているのですが、その原因が先週直ったみたいで、その問題点がメモリ圧迫の原因かも知れません。そうすれば、Seasar2か他のフレームワークの問題が解決されたことで、メモリ圧迫がなくなったのかもしれません。

方針を決めるその2

前回(方針を決める)の続きです。

異常系・正常系の順とするとは、前回の記事のサンプルコードのように、まずは異常となるデータをセットし、テスト対象メソッドが適切にエラー手続きを行っているかを先に調べるためです。

なぜ、異常系が先かと言うと、メソッドの中では事前にチェックを行って、問題なければ先に進む処理になっているのが多いことでしょう。

前回のサンプルコードでは、「search」メソッドの中で次のような処理を行っていました。

if (dataBean == null) {
    // エラー処理
}
if (dataBean.getName() == null) {
    // エラー処理
}
・・・
// 検索処理

異常系から調べることによりメソッドの処理の順でテストすることが出来るのです。


正常系からテストしようとすると、全て正しい場合のデータを入れる必要があり、最初にすべてソースを見渡す必要が出てきます。

今の説明ですと、誤解されてしまうかもしれませんので、補足します。
テストの場合は、

このデータの場合やこの場合ならこうならないといけないと仕様が決まっています

ので、テストするときにはテスト対象のメソッドは見なくてもある程度のテストが出来ないとおかしいです。

  例えば、ソースコードの仕様が「引数がnull」の場合なら○○例外をスローする。挿入処理なら、権限が無いユーザが登録しようとしたら××例外をスローすると決まっていることでしょう。

決まっていれば、まずは「引数の値がnull」になるように進めていきます。全て適切な値を入れた後に、存在しないユーザや権限のないユーザで試していくことにより、徐々に正常系に近づけてテストを作成して行きます。


junitを使う場合というのは、単体レベルのテストを行う場合に使うことが多いので、ホワイトボックスのテストになるので、テストはテスターではなく実装者が行うのが普通でしょう。そのため、進め方としては、ソースを見ながらテストを作成する方が多いでしょう。

ただ、最初からソースを見るのではなく、まずは、この場合ならこうならないといけないというテストを先に進めてから進めるのが良いでしょう。

ホワイトボックスの話も出しましたが、一通り仕様を満たす試験を行い、後はテストするクラスがすべてテストされているかどうかをカバレッジツールを利用することで確認するのが良いでしょう。

そして、カバレッジを調べた後にテストを追加するのも良いでしょう。そうすれば、実装者ならどこのテストが抜けていたのかわかり、ホワイトボックスのテストも満たすことになります。

カバレッジは、junitを使うのであればdjunitと併用することがお勧めです。


カバレッジを意識したテストをする場合、DAO、サービス、アクションのテストの順に調べるのは2回以上テストすることになるので、以下の方法で進めても良いと思います。

・アクション
一通りのテストを行う

・サービス
アクションのテストで処理されないテストを行う。

・DAO
サービス・アクションのテストで処理されないテストを行う。


アクションのテストで処理されないとは、アクションの中でチェックを行っていたり、他のサービスでチェックを行っていたために、その後に呼びだされたサービス・DAOのチェックまで処理が流れないことです。

つまり、アクションで一通りテストをして、サービス・DAOの個別にチェックしている処理はサービス・DAOのテストで行うということです。

  全てのアクションのテストで処理されないソースコードがあった場合、アプリ自体には不要ですが、メソッドで前提となる条件が整っているかをチェックするのはメソッド内でしたほうが拡張性がありますので、そう言った意味でも個別のチェックはサービス・DAOのテストですると良いでしょう。

方針を決める

Seasar2のテストに、s2Junit4を使っています。

既に、Junitでの試験をしたことがあるので、Junit4、s2Junit4で変更された箇所だけを習得してテストを行いました。


テストを行うときには、テストを行う前に方針を決めることにより、後は流れ作業のように進めることが出来ます。

例えば、まずはDAOから進めていき、サービス、アクションのようにテストの順番を決めることです。


今回の場合は、


DIされるオブジェクトの自体のチェックはしない

テスト用のデータを利用する

各メソッド一結果のテストとする

異常系・正常系の順とする


という方針で進めていきました。


上記の方針は私個人で決めたルールです。プロジェクト自体のルールも存在しますが、ルールをさらに厳格に決めることは後々の作業が楽になるからです。

テスト用のデータを利用するでは、s2Junit4を使うと便利です。s2Junit、s2Junit4では、「Excelファイル」を用意することで、データベースのテーブルにデータを簡単にセットすることができます。
Excelファイルの作成を参考。

データベースのテーブルを置き換えたい場合も、

TestContext ctx;

public void before() {
ctx.setPreparationType(PreparationType.ALL_REPLACE);
}

とすることで出来ます。
データベース上のデータをテーブルごとに完全に置き換えるを参考。


各メソッド一結果のテストとするとは、junitではテストクラスを作成するときに、テストするメソッドを指定して試験を行いますが、確認する項目によって、メソッドを分けるということです。

例えば、「search」メソッドがあった場合は、
public void testSearch() {
    try {
        DataBean dataBean = null;
        obj.search(dataBean);
        assertTrue(false);
    } catch (Exception e) {
        assertTrue(true);
    }
    try {
        DataBean dataBean = new DataBean();
        dataBean.setName(・・・);
   ・・・
        assertEquals(ctx.getExpected(), obj.search(dataBean));
    } catch (Exception e) {
        assertTrue(false);
    }
}

のように、複数のテストを1つのメソッドで行うのではなく、「testSearch1()」、「testSearch2()」、・・・のように、分けて行います。

残りの項目については後日。

Windows 7 + 64bit で Seasar2 を使う

私もsatoと同じく常駐しています。私は2月から参加しており、Searsar2に四苦八苦しながら作業をしています。


 Seasar2などのフレームワークを利用していることもあり開発環境のEclipseのメモリ使用量が常に100MBを超えています。Tomcatを常時起動するとそれ以上かも知れません。

パソコンは、当然常駐先のパソコンを使っているのですが、昨日新しいパソコンに交換していただきました。

そのパソコンは、なんと


「Windows 7」+「64bit」


という構成で、こんなところでWindows 7を使うことになると思いませんでした。

1月の案件では、エンドユーザさんが64bitの環境ということでテスト時には使っていたのですが、普段のパソコンとして使うのは初めてです。

メモリは、64bitを生かせる量で、CPUの性能も申し分ない構成と考えていただければ想像が出来ると思います。



開発は、Javaですし、開発環境もEclipse+TomcatなのでOSも64bitも悪い影響は無く、とにかく使い易いです。

Windows XP 64bitはさすがに使いにくかったですが、Windows 7の64bitは本当に快適です。

まあ、接続するものは付属のものだけなので、私が使う分にはドライバの影響なく、メリットだけしかないです。

「Windows 7」+「64bit」

は、Windowsではないではと思う快適さで、「Windows 7」+「64bit」が主流になってほしいです。


去年、Window 7発売前に、高性能のデスクトップパソコンを買いましたが、今思えば「Windows 7」+「64bit」でも良かったと思うぐらいです。


Seasar2の環境では、

Hot DeployのためにTomcatが常駐

DoltengのScaffoldによる自動生成

H2 Serverの起動

を使用することが多々あると思います。そのために、メモリ使用量もCPUの性能もあればあるほど恩恵を受けることが出来ます。

この恩恵は、自宅の高性能のデスクトップパソコンでも受けて、実感済みです。

夕飯はスーパーで

1月は何かと忙しいですよね。特に中旬から下旬にかけては、何かしらの締め切りがあることが多いので。

とか言っていると後1週間で1月が終わります。早いですね。

今日は金曜日なので、遅くまで会社で仕事しています。帰りが遅くなる場合は、いつものコンビニへ!

ただ、今日は違います!先輩がスーパーに行くと言うのでご一緒に行きました。先輩曰く一日2食コンビニじゃあねということで、私もスーパーで夕食を買いに行きました。

頑張って、遅くまで仕事した日には夕食だけではなく、帰りも贅沢にということで、特急で帰ります!

livedoor プロフィール
QRコード
QRコード
  • ライブドアブログ