haoyayoi Dev Style

iUnitTestを使った実際の開発進行

iUnitTest | 21:08 |

以前iUnitTestを使ったことをエントリにいれたものの、開発が進みまくった後での導入は中々手強いものがありました。

実際のテンプレートを使ったコーディングになかなか踏切にくいというのはあるかもしれないので、具体的なコーディングについてメモとして残してみます。

ModelはiUnitTest subclass

MVCのうち、ModelのテストにはiUnitTestが一番用いやすいと思います。

お手軽なやり方としては、宣言の方にテスト対象をインスタンス変数として含め、実装にてtestメソッド内にて生成。そしてASSERT_EQUALなりでテストを加える形。もしくは毎回testメソッド内にてローカル変数としてやってしまうのも手です。

#pragma mark -
#pragma mark Tests

- (void)test1
{
    TargetModel *targetmodel = [[TargetModel alloc] init];
    ASSERT_NOT_EQUAL(nil, targetmodel);
    ASSERT_EQUAL([TargetModel class], [targetmodel class]);
    [targetmodel release];
}

@end

tableとviewはUINavigationBarBasedTest

というよりも、単にUITabBarBasedな方を未だ踏み入れてないというだけだったりします。

iUnitTest内部にテスト用のNavigatonBarが含まれており、テストしたいtableviewcontrollerやviewcontrollerなりをそのBarに追加するという形です。

初期ではTableViewController用に記述されていますが、これをViewControllerに直すと

- (UIViewController *)rootViewController
{
    controller = [[ViewController alloc] initWithNibName:nil bundle:nil];
    return controller;
}

こんな感じになります。

コーディングのスタイル

あくまで私流です。

1.作成したいメソッド名を定義

@interface FakeClass : NSObject {

}
- (BOOL)fakeMethod:(id)sender;
@end

2.実装はせずに、テストクラスを作成

3.テストケースを書く

- (void)testFakeMethod {
    FakeClass *faker = [[FakeClass alloc] init];
    ASSERT_EQUAL_INT(YES, [faker fakeMethod:nil]);
    [faker release];
}

4.一度テストアプリを実行する（もちろんこける）

5.実装のコードを書くけど肝心な部分は実装しない

- (BOOL)fakeMethod:(id)sender {
    return sender;
}

6.一度テストアプリを実行する（あたりまえのようにこける）

7.肝心な部分をかく

8.テストアプリを実行する

といった繰り返しでした。一つ一つ足固めする感覚です。

iUnitTestをつかってみた

iUnitTest | 03:18 |

iUnitTest - リンゴの水やり？(はてな)

知ってることと使えることの差は大きい、と思ってとりあえず使ってみることにした。ドキュメントがあるからそれを参照しつつ。

とりあえず使ってみた感想

開発中のソースコードはそのままの状態で、色々な変更を加えつつテストできるのはものすごくラク。よくある「全部書いてまとめてテストした結果のみを確かめる」より見通しがよくて、すっきり書き上がる。

iPhoneアプリの性質上、小刻みなテストは必要不可欠だろうし、使うことになれていきたい。