イントロダクション

Ajile開発のワークショップに行ってきました。
とても、有意義かつ、勉強になったワークショップでした。
そんなわけで、学んだことをまとめます。

早い話が、こーゆーやり方すると効率的に開発が進められるというものでした。

Ajile開発とは

早い話が、動くものを作りましょう。

と言うことですが、はじめからみんなそう考えてるのでは？と疑問に思うと思います。それは歴史的な経緯があります。

歴史的な経緯

昔は、パソコンがなかったので、コードを一度にコードを書ける人(コンピュータにプログラムを実装する人)が限られていました。1人一台のパソコンは無かったので大きなコンピュータしかなく、現代の様にみんなでワイワイとコードをかけませんでした。

しかし時代は変わり1人一台のパソコンを使用して巨大なシステムの実装が可能になり、それが普通になってきました。

昔のやり方

1人しかコードの実装ができないので設計レベルでしっかり作り後はコードを書くだけで良い形をとっていました。が、システムが巨大になり、昔のやり方では追いつかなくなってきました。なので下のように実装してました。

どのように動くのか、仕様を決める
設計をする
実装する
テストする
リリース

今のやり方

どのように動くのか、仕様を決める
テスト仕様を作る
設計をする
実装とテストを並行して行う
リリース

テストがはじめの方に来ます。

これで何が変わるのか？ズバリ実装が終わってからの仕様偏向が減ります。

仕様変更は、色んな原因で発生しますが、少なくとも設計ミスでの仕様変更はテスト中に発見できるので、作業の手間が減ります。その他色んなメリットがありますが、「やった事がない」という理由で日本には浸透していません。。。(2021年現在)

Wikiを参照すると下のようなものでした。

アジャイルソフトウェア開発手法の多くは、反復 (イテレーション) と呼ばれる短い期間単位を採用することで、リスクを最小化しようとしている。 1つの反復の期間は、プロジェクトごとに異なるが、1週間から4週間くらいであることが多い。
アジャイル開発手法においては、開発対象を多数の小さな機能に分割し、1つの反復 (イテレーション) で1つの機能を開発する（⇒反復型開発）。そして、この反復のサイクルを継続して行うことで、1つずつ機能を追加的に開発してゆくのである。また、各々の反復は、小規模なソフトウェア開発プロジェクトに似ている。なぜなら、計画、要求分析、設計、実装(コーディング)、テスト、文書化といった、ソフトウェアプロジェクトに要する全ての工程を、1つの反復内で行うからである。

そして、まとめると開発の作業範囲を限定して、細かく作業を分けて、その単位で開発を行うということです。

具体的に

例えば、コンソール出力版テキストRPGを作成するプロジェクトがあったとします。その時に作成するべき内容は以下の通りです。※自分で作成するのにこのような仕様にしました。

作成する項目(仕様)(TextRPG)

戦闘シーンを作成する(単体のモンスターと)
複数モンスターとの戦闘
仲間を加え戦闘することができるようにする
プレーヤーがレベルアップできるようにする
ストーリー展開のシーンを表示できるようにする
タイトルを表示をできるようにする
ストーリー展開と戦闘シーンの切り替えをできるようにする
タイトルとストーリー展開シーンの切り替えをできるようにする
タイトル～戦闘シーンまでの切り替えをできるようにする
ストーリー展開シーンの中でストーリーを進行させることができるようにする
装備などでステータスを、変更できるようにする
町などで、買い物ができるようにする
アイテムの使用ができるようにする(戦闘シーンも含む)
エンディングを表示できるようにする

上記のように、各仕様に対してその実装を行うのですが、その仕様でちゃんとアプリケーションが動くように作成していきます。つまりは、以下の様なバージョン分けを行い「このレベルで動くアプリケーション」と言う区切りを設けて作り込んで行きます。

そして、ポイントになるのがテスト駆動開発です、それは、各仕様を実装していくのに、先に仕様を決めて、その通りに動くか確認しながら実装していくためです。そして、実装した部分を修正し続けていく必要があるため他に影響が出ないか確認するです。

ここで、テスト仕様から作成し、動きを確かめながら実装してくのもそうですが、修正するときに「テストが通ればどんな修正でもOK」という形にしておけば修正も楽だしレビューだって楽にできる状態になります。
つまり、レビューワーはテスト仕様がちゃんと組まれているか？を確認、テストの実行結果もOKということを確認するだけでよいのです。

「楽」というのは、作業時間が少なくて済むということです。空いた時間はほかの作業を行えばよいので仕事にも余裕ができます。

テスト駆動開発に関してはこちらの記事に詳細を記載しています。

Java ミニゲームソース付き〜テスト駆動開発：文言出力部品を作る〜

JUnitの使い方～テストクラスの作成と実行～

スクラムフレームワーク

アジャイル開発の現場では「スクラム」というフレームワークを使用することが多いようです。リンク先はWikiです。
このフレームワークは、下のようなフローで作業を行うと作業効率がよく、作業員が成長できるというスグれものです。Springなどのフレームワークと違いプログラミング用のフレームワークではありません。

スクラムに登場する役割

開発チーム: プログラマーチーム
プロダクトオーナー: 製品の総責任者。顧客の意思の代表としての役割を担う。
スクラムマスター: チーム内外の組織間調停( ファシリテーション )と外部妨害を対処することとされる。顧客側で担当することが多い。

作業その1：バックログの作成

製品に対する「要求」を作成すること、上の仕様がこの部分に当たる。
上の仕様は、大まかなものなので、これらの仕様を実現するための仕様(タスク)を実現するために「スプリント」という期間を作り、対応する。

作業その2：スプリントの作成

スプリントは上記の「要求」を実現するための「タスク」を切り出して、特定の期間内で完了するための作業です。バックログを作成(タスク切り出し)→スプリント(実行項目切り出し)というような流れになります。

スプリントプランニング

チームはスプリントで実現するバックログの項目を選択
選択したバックログ項目を実現するためのタスク化を行う
チームが共同でタスク化する過程で、チーム内メンバーの認識差異がないことを最終確認する。

デイリースクラム

毎日スクラム会議を開く。
平日の決まった時間に決まった場所で行う。また、15分以内で完了させなければならない。
スクラムマスターは、必ず出席、チーム全員に対して、以下の質問を行う
- 1. 「前回のスクラム会議以降、何をしたか」
- 1. 「問題はあるか」
- 1. 「次回のスクラム会議までに何をするか」
問題があると報告された場合、スクラムマスターは、即座に意思決定する責任を負う。問題が外的要因によるものである場合、スクラムマスターが、その解決の責任を負う。

プロダクトバックログ・リファインメント
実際に行う作業の見積もりを行う、作業量がどのくらいか？期間内で完了できるか？を見積もるのにポイントを振り分ける。
初めて、行う作業に関しては、実際にポイントを振って行いその結果「XXポイント」でどのくらいの時間が必要だったか？の平均をとり、おおよその見積もりを取る。
(例)

タスクA,B,Cとあったときに基準にするタスクを決めポイントを割りふる。この時は直感で判断して良い。そして。チーム内でそのポイントを割り振った理由を言う
基準にしたタスクから「これぐらい」という見積もりをチームのメンバー内で話し合いで決める。この時に時間をかけないように注意する。
実行してみて、その結果、ポイントの消化がどれくらいでできたか？の平均値を取り基準にする

スプリントレビュー
スプリントレビューでは、スプリントで開発されたソフトウェアのレビューが行われ、必要に応じて、新たなバックログ項目が追加される。つまり、参加者の中に顧客がいるのでレビュー時に追加の要望などが出てきたりする。
このレビューには、顧客、マネージャ、開発者が参加する。
なお、場合によっては、営業やマーケティング関係者も参加する場合もある。

スプリント・レトロスペクティブ（振り返り）
振り返りを行う。その振り返りのフレームワークとして以下のものがある。
各項目に対して意見をメンバーで出して、それを話し合い次のスプリントへつなげる

KPT: Keep, Problem, Try
YWT: やったこと、わかったこと、次にやること
FDL: Fun(面白かったこと), Done(やったこと), Learn(学んだこと)

モブプログラミング

実装者一人、他は全部レビューワー。の形で実装を進めるプログラミング方法。

実装者の技術レベルが近く、互いに切磋琢磨できる関係ができていればとても有意義なプログラミング手法。

実際にやってみて面白かった。

また、技術レベルが離れている状態で行った場合には実践的な指導ができる。

ペアプログラミング

これも、上記同様実装者一人、レビューワー一人で実装を行う。

まとめ

スクラムフレームワークを使用してチーム開発を行うときに下のようなツールを使用するとやり易い。

Gitなどのバージョン管理ソフト
意見交換するためのツール、ウェブホワイトボード、スケッチブックなど
時間の管理を行うタイムキーパー
チームの活動を見守る人

自分の参加したワークショップは仕事ではなく、「学習」だったのでとても楽しかったが「仕事だと楽しくないよな。。。」という意見もありました。

最も作業効率が良く、生産性の高い現場というのは、「楽しく仕事ができる」というところだと思いました。

また、テスト駆動開発がちゃんと出来ていれば、仕様変更に対してもすぐに対応可能だという事に気がつきました。

具体的には、仕様変更があったときに、どの部分を修正するか確認したら、既にあるテストクラスに修正点を確認するコードを書き、それが通れば仕様変更完了になる。という事です。

もちろん。自動テストで、周りに影響がない事を確認します。

でわでわ。。。

JavaFX関連ページ

ステップアップ関連ページ一覧

JavaFX + ND4Jで機械学習準備

オブジェクト指向関連ページ

[オブジェクト指向の概念1〜OracleDocのチュートリアル１〜](https://zenryokuservice.com/wp/2019/10/301. /%e3%82%aa%e3%83%96%e3%82%b8%e3%82%a7%e3%82%af%e3%83%88%e6%8c%87%e5%90%91%e3%81%ae%e6%a6%82%e5%bf%b5-%e3%80%9coracledoc%e3%81%ae%e3%83%81%e3%83%a5%e3%83%bc%e3%83%88%e3%83%aa%e3%82%a2%e3%83%ab%ef%bc%91/)
オブジェクト指向の概念2〜クラスとは〜

Java ミニゲームソース付き〜テスト駆動開発：文言出力部品を作る〜

今回は、RPGゲームでよくある文字を１文字ずつ読めるスピードで出力する部品を作ります。

今まで作成したテキストRPGゲームに追加します。
現状は、こんな感じで動きます。

文字の出力は、一括で出力するのでゲームっぽくありません。どちらかというとログ出力っぽいです(笑)

文字出力部品を作る

現状は、System.out.println()を使用しています。これは引数にある文字列を標準出力に出力します。
標準出力 = System.outになります。

問題

どーやって１文字ずつ出力するか？
とりあえずは、テスト駆動開発にしますので、テストケースを作成します。

毎度おなじみJUnit

JUnitを使用してテストクラスを動かします。

作成手順

Eclipseのプロジェクトに「test」フォルダを作成する
テストするクラスと同じパッケージを作成する
テストするクラスの後にTestをつけたクラスを作成する
〜Testクラスにテストケースを作成する

具体的に。。。

実装した時の動画を作成しました。

詳細は以下のようになります。
上の手順４以降の記載になります。

JUnitをビルドパスに追加

動画にもあるのですが、上のような画面でJUnitを追加します。細かい部分は動画にありますので参照ください。

テストケースを作る

今回のテストケースはコンソールにゆっくりと表示できれば良いので、動かすだけになります。
故に、コードは下のようになります。

public class PrintUtilsTest {
    @Test
    public void testPrint01() {
        String mes = "アイウエオカキクケコ。。。。";
        try {
            PrintUtils.print(mes);
        } catch (InterruptedException e) {
            fail(e.getMessage());
        }
    }
}

今回の作成するクラスは、PrintUtilsクラスです。テストクラスは上のコードにある通りです。

作成するクラスをガワだけ作ったら、あとは、テストケースで呼び出してやる処理を実装してやるだけです。

あとは、実装→起動→修正→確認を繰り返して終了です。

シンプルなもんです(笑)

JUnitを使用したときの再生リストへのリンクです。

JUnitで10進数を2進数に変換する処理を実装

テストファーストで、補数算出メソッドの実装

EclipseでJUnitの起動設定～テストクラスの作成１

EclipseでJUnitの起動設定～テストクラスの作成２

Java テスト駆動で引き算のメソッドを作る

JavaFX関連ページ

ステップアップ関連ページ一覧

JavaFX + ND4Jで機械学習準備

オブジェクト指向関連ページ

[オブジェクト指向の概念1〜OracleDocのチュートリアル１〜](https://zenryokuservice.com/wp/2019/10/301. /%e3%82%aa%e3%83%96%e3%82%b8%e3%82%a7%e3%82%af%e3%83%88%e6%8c%87%e5%90%91%e3%81%ae%e6%a6%82%e5%bf%b5-%e3%80%9coracledoc%e3%81%ae%e3%83%81%e3%83%a5%e3%83%bc%e3%83%88%e3%83%aa%e3%82%a2%e3%83%ab%ef%bc%91/)
オブジェクト指向の概念2〜クラスとは〜

Java はじめて31 〜JUnitでのテスト駆動型開発8: 処理をつなげたテスト〜

イントロダクション

今まではユニットテスト(単体テスト)をやっていましたが、複数のクラスを実行するテストケースも作成することができます。
プログラム的には、実行するプログラムを増やすだけですが。。。

イメージとしては、メインメソッドを動かすテストを実行するようなイメージです。
そうすれば、メインメソッドを動かした方が早いような気がしますが、大掛かりなアプリケーションの場合は、そうもいきません。

なので、「足し算をする処理のテスト」「ファイルを読み込むテスト」とテストを行った後に、口座に入金するテストをするというような形です。

今回のような小さなプログラムでは、あまり意味がありませんが。。。

今回は、今まで作成した１処理を「機能」として動かせることを確認するテストケースを作成します。
通常のやり方では、1.実装、2.テストと分けた場合の「2.テスト」にあたります。

機能テスト

仕様は以下の通りです。

仕様: 1. ファイルを操作するためのオブジェクトを作成する; 2. ファイルにデータをCSV形式で書き出す。; 3. ファイルが存在するのであれば、それを読み込みデータを保持する

今までの実装、テストで行くと「3」が実装したものに相当します。なので、これをテストケースで確認する様にします。
現状では、スタブのままなので未実装になっています。
なのでテストケースを先に作成します。
ちなみに、最終的なコードはGithubにあります。

@Test
public void testFileRead() {
    if (target.isFile() == false) {
        fail("ファイルが存在していません");
    }
    List<Data> dataList = target.readFile();
    // データは１件
    assertEquals(1, dataList.size());
    // ファイルにあるデータ
    Data data = dataList.get(0);
    assertEquals("test", data.getName());
    assertEquals("passwd", data.getPassword());
}

とりあえずで、上の様に作成しました。初めにファイルの存在チェック処理を確認して、ファイルが存在しないならテスト失敗。
次にファイルの読み込みを行い、そのデータを取得しデータが想定通りのものが入っているか確認します。

余談

テストを複数回行っていたので「koza.csv」にデータが複数作成されていました。ヘッダー付きなのでこれはダメなテストになってしまうので、ちょっと修正します。
＜修正１＞
「ファイルが存在するときにはファイル作成をしない」が抜けていたのでこれを追加します。

// ファイルそ新規で作成するとき
if (file.exists() == false) {
    // ヘッダー部分の出力
    build.append(this.createCSVHeader());
    // ファイル書き込み処理
    write.write(build.toString());
    write.newLine();
}

そして、修正後のメソッドは以下の様になります。

public void dataOutput(Data data) throws IOException {
    if (file.canWrite() == false) {
        throw new IOException("ファイルの書き込みができません: " + file.getAbsolutePath());
    }
    // おおよそのデータサイズを指定すると余計なメモリを使用しなくて済む
    StringBuilder build = new StringBuilder(50);
    // ファイルを新規で作成するとき
    if (file.exists() == false) {
        // ヘッダー部分の出力
        build.append(this.createCSVHeader());
        // ファイル書き込み処理
        write.write(build.toString());
        write.newLine();
    }
    // StringBuilderのクリア
    build.setLength(0);
    // データ部分の書き込み
    build.append(data.getName() + ",");
    build.append(data.getPassword());
    write.write(build.toString());
    write.newLine();
    write.close();
}

これで、ファイルが存在しているのに新たにファイルを作成することがなくなります。

しかし、テストはうまくいきませんでした。
これの原因は、テストケースにありました。

@Test
public void testFileRead() {
    if (target.isFile() == false) {
        fail("ファイルが存在していません");
    }
    List<Data> dataList = target.readFile();
    // データは１件
    assertEquals(1, dataList.size());
    // ファイルにあるデータ
    Data data = dataList.get(0);
    assertEquals("test", data.getName());
    assertEquals("passwd", data.getPassword());
}

取得したデータのサイズ(ファイルの行数)は１の想定ですが、テストを実行するたびにデータが追加されるので、テストが毎回同じ結果になりません。

これは良くない

なので、ここもちょっと修正します。

// データは0件ではない
assertNotEquals(0, dataList.size());

こんな感じで修正しました。そして、複数件あっても作成されるデータは同じなので初めの一件目が想定通りの値かどうか確認します。ここでちょっと注意「初めの1行目はヘッダー行なのでデータ部ではないですが、取得したときはリストの１番目に設定されています。なので以下の様に修正します。

public void testFileRead() {
    if (target.isFile() == false) {
        fail("ファイルが存在していません");
    }
    List<Data> dataList = target.readFile();
    // データは0件ではない
    assertNotEquals(0, dataList.size());
    // ファイルにあるデータは2行目から
    Data data = dataList.get(1);
    assertEquals("test", data.getName());
    assertEquals("passwd", data.getPassword());
}

こんな感じでファイル読み込みの一連の機能をテストしました。これと同様に、他ものもテストしました。わかりづらいですが、上のキャプチャにテストケースが、４つあります。
ファイル作成、ファイル存在チェックの処理の他は読み込みと書き込みをテストしています。

ちょっと締まりが悪いですが。今回はこれまでにします。

ここまでで31回分の学習を行いました。ここまで来たら(もしかすると途中で。。。)自分で考えて学習を進めることができるレベルまで来ているのではないでしょうか？「いや？」という声がないと良いのですが、「物事を伝えるのは至難」とも言います。また別な角度で同じことを記述したいと思います。
「Jaba Basic Lv1」と称して再度記載しました。こちらも併せてご利用ください。

でわでわ。。。

<<< 前回

＜Java関連の動画リスト＞

＜JUnit関連の動画リスト＞

Java はじめて30 〜JUnitでのテスト駆動型開発7: テストクラスの実装方法〜

イントロダクション

前回までは、部分的にテストケースなどを作成してきましたが、テストケースの作成をするために必要なこと〜実装までを記載したいと思います。

今回は、まとめ的に、JUnitでの実装をやります。今までは、コードを書き終わったものを記載していましたが、今回はコードを書きながら記載していこうと思います。自分のやり方になりますが。。。

テストクラスの実装方法

仕様確認1

koza.csvファイルが存在するときはファイルを読み取り、それをDataクラスに設定し、リストにして返す
koza.csvがない場合は、システムエラーを出す

上の仕様を満たす様に、テストケースを考えます。シンプルなもので、単純に実装すれば良さそうです。
「〜そうです。」と記載したのは、実装などはやってみないとわからないこともあるのでこの様に記載しました。早速作ってみます。

テストケースを作る

まずは、単純にテストクラスを作成します。このクラス名は「テスト対象クラスの名前+Test」という形で作成します。
テストクラスと実装するクラスのセットが、そうするとわかりやすいからです。すでに実装していますが「初めから作る」という前提で記載します。

※　「スタブ」というのは空実装、つまりメソッドの名前、引数、返り値を書いているけど中身のない状態です。
```java
/** スタブ実装 */
public void stubMethod() {
}
```

作成するクラス: KozaManager(実装クラス); KozaManagerTest(テストクラス)

＜実装クラス＞

public class KozaManager {

    public Listl<Data> fileRead() {
        // 実装前なのでスタブにします。
    }

}

＜テストクラス＞

public class KozaManagerTest {
    @Test
    public void testFileRead() {
        // これもスタブ
    }
}

現状は、上記の様な状態です。
そして、考えます。何を？。。。仕様の１番目「koza.csvファイルが存在するときはファイルを読み取り、それをDataクラスに設定し、リストにして返す」にはどの様なテストが必要か？を考えます。単純に考えるならば以下の様になります。

ファイルの存在を確認する処理が想定通りに動くか？
ファイルが存在するならば、それを読み込みデータリストを返却するか？

そして、もう１つの仕様「koza.csvがない場合は、システムエラーを出す」に関しては

ファイルが存在しないときはシステムエラーを出し、アプリケーションを終了するか？

それぞれ、上の様なチェック(テスト)を行います。ぶっちゃけて、まずはこの単純な確認を行ってから次に「穴はないか？」を考えれば良いと思います。

なのでシンプルにその様なテストケースを作成します。
まずは、「ファイルの存在を確認する処理が想定通りに動くか？」これを確認するために実装クラスとテストクラスの両方を修正します。着手するのは１つずつなので安心ください。
ますは、テストケース(テストクラス)
＜テストクラス＞

public class KozaManagerTest {
    @Test
    public void testIsFile() {
        // ファイルの存在チェック処理の確認
    }
    // 今はテストしないのでコメントアウト
    // @Test
    public void testFileRead() {
        // これもスタブ
    }
}

とりあえずは、ファイルの存在チェック処理を動かすためのテストケース(メソッド)を作成しました。
ここで、足りないものがあります。

テスト対象クラス(実装するクラス)
ファイル存在チェック処理メソッド

通常の開発だと、これらを実装してからテストしますが。先に箱(スタブ)だけ作ってしまいます。
＜実装クラス＞

public class KozaManager {
    public boolean isFile() {
        // とりあえずスタブです。ファイルが存在していることを確認する
    }
    public Listl<Data> fileRead() {
        // 実装前なのでスタブにします。ファイルを読み込めることを確認する
    }

}

そして、ちょっと考えてみると「ファイルの存在チェック処理を行うのに、ファイル名が必要だな。。。」と気がつくと思います。

ここが悩みどころ

ファイル名を(引数で)渡す処理方法と、ファイル名を固定して渡す方法のどちらもできるので「どちらの手段が汎用性、保守性共に高いだろうか？」と悩んでみます。
自分の結論は「引数でファイル名を渡す」方が良いと思ったのですが、すでに実装ているコードではコンストラクタでCSVファイルを読み込んでいるので今回は、引数なしでのメソッドにします。つまり、処理の順序的にCSVファイルを読み込んでから呼び出す処理になっているという意味です。コンストラクタの実装は下のように作っています。※設計的にビミョウな感じがします。。。
```java
public class KozaManager {
/** ファイルへの書き出しクラス */
private BufferedWriter write;
/** ファイルの読み込みクラス */
private BufferedReader read;
/** 取得(作成)するファイルクラス */
private File file;

/** コンストラクタ */
public KozaManager() {
// 操作するファイルを指定する
file = new File(FILE_PATH);
try {
write = new BufferedWriter(new FileWriter(file, true));
if (file.exists()) {
read = new BufferedReader(new FileReader(file));
}
} catch (IOException ie) {
ie.printStackTrace();
System.out.println("ファイルオープンに失敗しました。" + ie.getMessage());
System.exit(-1);
}
}
}
```

なので以下の様なコードになります。
＜実装クラス＞

public class KozaManager {
    /** 作成するファイルが存在するかチェック */
    public boolean isFile() {
        // fileはフィールド変数
        return file.exists();
    }
    public Listl<Data> fileRead() {
        // 実装前なのでスタブにします。
    }
}

＜テストクラス＞
テストの実行前に、テスト対象クラスのインスタンスを作成(newする)し、フィールド変数にセットします。
つまり、以下の順序で処理が走ります。

1. 「\@Before」アノテーションのついているメソッド
2. 「\@Test」アノテーションのついているメソッド

テストケースの数だけ「\@Before」が動きます。

public class KozaManagerTest {
    @Before
    public void initTest() {
        target = new KozaManager();
    }

    @Test
    public void testIsFile() {
        // コンストラクタでファイルが作成されることに注意
        assertTrue(target.isFile("koa.csv"));
    }

    // 今はテストしないのでコメントアウト
    // @Test
    public void testFileRead() {
        // これもスタブ
    }
}

実行結果は下にあります。

まとめ

「テストケースを作る＝実装を行う」順序

１．作成するプログラムの仕様を確認する

仕様を満たすテストケースを考える
考えたテストケースを実装する(スタブ)※テストする内容をコメントしておくと良い
実行するクラス(KozaManager)を実装する
テストケースを実行(KozaManagerTest)して、処理が正しいことを確認

クラス、メソッドの依存度が高いと右を修正した後に左を修正。。。と無限ループすることがあるのでそれぞれの処理が(なるべく)独立するように作りましょう。

でわでわ。。。

<<< 前回次回（ラスト) >>>

＜Java関連の動画リスト＞

＜JUnit関連の動画リスト＞

Java はじめて29 〜JUnitでのテスト駆動型開発6: ファイル読み込みのテスト〜

イントロダクション

前回は、ファイルの出力を実装しました。
もちろんテストケースありきの実装です(テスト駆動開発)。ここまでくると、だんだんと実装とテストと慣れてくると思います。
横っ飛びして、別なプログラムを作成し始めてみるのも１つです。

わからなくなったら、また調べれば良いのです。

今回は、今迄作成した「ファイル存在チェック」と「ファイル作成、更新」処理を繋げてテストします。

この段階で、ようやくテストらしいテストになります。ちなみにこのテストケースも実装前に作成出来ますが、小さなレベルで、テスト仕様を考える→実装→テスト実施…とやった方が早い気がします。

口座作成処理

ようやく、仕様レベルの話に戻って来ました。このテストケースはコーダー銀行に口座を開設する処理に当たりますので、実際に動かす時と同じような入力(テストなのでデータ)を渡して実行します。テストコードは下のようになります。

このテストケースが通ったらとりあえずは、製造完了です。お疲れ様でした。

ひと段落したので、一旦休むも良し、このまま突走るのも良し。

他の事に着手してみるも良し！

動く事が大事

何が言いたいかと言うと、プログラムは何かを作る、仕組みを作るなどに使用する。若しくは単純に触りたいだけ…など色々あると思いますが、ちゃんと動くモノを作った方が、実力もつくし、作ったもので遊べるし、良い事ずくめだと思うので、色々と作ってみるのが良いと思います。

今迄やって来ているのは、サンプルなので…主な目的は「Javaの学習」になっています、あまり作りたいものには届かないと思います。しかし、基礎を学べる様になっているのと、コンソールアプリなので応用はいくらでも出来ます。早い話が、コンソールアプリが作れれば、あとは環境が違うだけなので大まかな流れは理解できるずです。。。

続き

前置きは、このくらいにして、続きをやります。

早い話が、今迄作成したメソッドを続けて呼び出し、それらが想定通りに動くか？の確認を行います。

作成したメソッドは以下のものです。

そして、上のメソッドを結合してやる場合のテストケースから考えます。

データの読み込み

仕様

ファイル存在チェックを行いファイルが存在すれば読み込む
存在しなければファイル作成を行う

仕様に関してはこの部分のみをみていましたが、ファイルの読み込みをした後に、データが入っているはずなので、これを取得する必要があります。

この部分は実装していないので、実装が必要です。とりあえずは、目の前のテストを片付けてしまいます。テストコードは下の様になりました。テストを実施しながら実装するので手直しをするからこうなりました。と言う表現を使いました。

テストが通ったので、次の事を考えます。つまり、ここまでは想定通りに行ったという事です。

データの取得

次は、読み込んだファイルのデータをクラスに設定してやる事を考えます。

ファイルに保存してあるデータを読み込んで、プログラムで使いやすい様にデータクラスを使ってデータを保持します。「保持」と言うのは、プログラムが止まると消えてしまう情報なので「保持」と言う言葉を使いました。

ちなみに、ファイルに保存すれば、プログラムが止まっても情報は残しておけます。

現状では、Dataクラスを使用してファイルにデータを書き込んでいます。
ちなみにデータクラスは下の様なコードになります。

＜補足＞
データクラスとは：クラスにフィールド変数、ほかはGetter,Setterが定義してあるだけのクラスのことです。
わりかし身近なものとしては、ログインするときのユーザー情報クラスがこれに当たります。設計思想によりユーザー情報クラスに何かしらの処理を持たせることがあるかもしれませんが、筆者が作るのであれば、ユーザークラスの親(スーパー)クラスに持たせます。

はっきり言って、設計思想のレベルなのでどちらが良いとかっていう話ではありません。。。

public class Data {
    /** ユーザー名 */
    private String name;
    /** パスワード */
    private String password;

    /** 
     * コンストラクタ。口座情報を保持するクラスのインスタンスを生成。
     * 
     * @param name 口座のユーザー名
     * @param password 口座のパスワード
     */
    public Data(String name, String password) {
        this.name = name;
        this.password = password;
    }
    /**
     * @return the name
     */
    public String getName() {
        return name;
    }
    /**
     * @param name the name to set
     */
    public void setName(String name) {
        this.name = name;
    }
    /**
     * @return the password
     */
    public String getPassword() {
        return password;
    }
    /**
     * @param password the password to set
     */
    public void setPassword(String password) {
        this.password = password;
    }
}

読み込み時にもこのクラスが使えます。
まとめると以下の様な手順でファイルを読み込みます。

ファイルを開く(コンストラクタで実装ぞ済み)
ファイルを1行ずつ読み込みDataクラスへ設定
データクラスをリストにして返却する

以上の様な手順でファイルからデータを取得します。
そして、これをテストケースにします。

テスト仕様

上の手順そのままですがこれを確認するためのテストケースを作成します。そしてこれもとりあえずは「スタブメソッド」を作成します。

/**
 * ファイルを読み込みデータをリストにして返却する
 * @return List<Data> CSVファイルのデータリスト
 */
public List<Data> readFile() {
    return null;
}

このメソッドはJavaDocコメントにある様に、リストにしてデータを返しますので、java.util.Listインターフェースを使用してデータを返却します。
Listインターフェースの配列型リスト=ArrayListクラスを生成してデータをセットする様に実装します。コードは以下の様になります。

public void testFileRead() {
    List<Data> dataList = target.readFile();
    // データは１件
    assertEquals(1, dataList.size());
    // ファイルにあるデータ
    Data data = dataList.get(0);
    assertEquals("test", data.getName());
    assertEquals("passwd", data.getPassword());
}

このテストケースを実行しエラーが出ない様なコードを作成します。一応、CSVファイルはファイル作成時に出力したデータが設定されていることを確認しています。

まとめ

テストケースを作成して実行。。。これに関してどんなことをやったのか？に関して記載しました。
「データクラス」というのが新しい単語として出てきましたが、上記の通り「フィールド変数、Getter,Setterのみのクラス」というだけです。

でわでわ。。。

<<< 前回次回 >>>

＜Java関連の動画リスト＞

＜JUnit関連の動画リスト＞

イントロダクション

Ajile開発とは

歴史的な経緯

昔のやり方

今のやり方

具体的に

作成する項目(仕様)(TextRPG)

スクラムフレームワーク

スクラムに登場する役割

作業その1：バックログの作成

作業その2：スプリントの作成

モブプログラミング

ペアプログラミング

まとめ

関連ページ一覧

EclipseセットアップWindows版

Eclipse セットアップ

Git関連

JavaFX関連ページ

ステップアップ関連ページ一覧

JavaFX + ND4Jで機械学習準備

オブジェクト指向関連ページ

文字出力部品を作る

問題

毎度おなじみJUnit

作成手順

具体的に。。。

JUnitをビルドパスに追加

テストケースを作る

JUnitで10進数を2進数に変換する処理を実装

テストファーストで、補数算出メソッドの実装

EclipseでJUnitの起動設定～テストクラスの作成１

EclipseでJUnitの起動設定～テストクラスの作成２

Java テスト駆動で引き算のメソッドを作る

関連ページ一覧

Eclipse セットアップ

Git関連

JavaFX関連ページ

ステップアップ関連ページ一覧

JavaFX + ND4Jで機械学習準備

オブジェクト指向関連ページ

イントロダクション

機能テスト

余談

これは良くない

イントロダクション

テストクラスの実装方法

仕様確認1

テストケースを作る

ここが悩みどころ

まとめ

イントロダクション

口座作成処理

動く事が大事

続き

データの読み込み

仕様

データの取得

テスト仕様

まとめ