Custome UITableViewCellの[self addSubview]と[self.contentView addView]の違い

UITableViewCellを継承してカスタムセルを作成する場合に
self.contentViewに対してaddSubviewするのと
selfにaddSubviewするのとではぱっと見同じでどこが違うんだろうというところが気になったので調べてみた。

わかりやすく背景に色をつけてやってみた。
赤背景 : contentView
青背景 : subviewに追加するview

self版

- (id)initWithStyle:(UITableViewCellStyle)style reuseIdentifier:(NSString *)reuseIdentifier

{

    self = [super initWithStyle:style reuseIdentifier:reuseIdentifier];

    if (self) {

        self.comment = [[UILabel alloc] initWithFrame:CGRectMake(10, 10, 200, 30)];

        [self.comment setBackgroundColor:[UIColor blueColor]];

        [self addSubview:self.comment];

        [self setBackgroundColor:[UIColor blueColor]];

        [self.contentView setBackgroundColor:[UIColor redColor]];

    }

    return self;

}

self.contentView版

- (id)initWithStyle:(UITableViewCellStyle)style reuseIdentifier:(NSString *)reuseIdentifier

{

    self = [super initWithStyle:style reuseIdentifier:reuseIdentifier];

    if (self) {

        self.comment = [[UILabel alloc] initWithFrame:CGRectMake(10, 10, 200, 30)];

        [self.comment setBackgroundColor:[UIColor blueColor]];

        [self.contentView addSubview:self.comment];

        [self setBackgroundColor:[UIColor blueColor]];

        [self.contentView setBackgroundColor:[UIColor redColor]];

    }

    return self;

}

普通にaddSubviewするだけだと同じ。

http://developer.apple.com/library/ios/#documentation/UserExperience/Conceptual/TableView_iPhone/TableViewCells/TableViewCells.html#//apple_ref/doc/uid/TP40007451-CH7-SW1

ドキュメント見るとcontentViewの領域は編集とかアクセサリーViewと被らないようにするためっぽい。

■アクセサリーViewを有効にしてみる

- (id)initWithStyle:(UITableViewCellStyle)style reuseIdentifier:(NSString *)reuseIdentifier

{

    self = [super initWithStyle:style reuseIdentifier:reuseIdentifier];

    if (self) {

        [self setAccessoryType:UITableViewCellAccessoryCheckmark];

        

        self.comment = [[UILabel alloc] initWithFrame:CGRectMake(10, 10, 200, 30)];

        [self.comment setBackgroundColor:[UIColor blueColor]];

        [self addSubview:self.comment];

        [self setBackgroundColor:[UIColor blueColor]];

        [self.contentView setBackgroundColor:[UIColor redColor]];

    }

    return self;

}

contentViewの領域が変わった

■編集モードにしてみる( [tableview setEditing:YES] )

self版

self.contentView版

■TableViewのスタイルをグループにする( UITableViewStyleGrouped )

self版

self.contentView版

結論とするとTableViewのスタイルをグループにしたり、編集とかaccessoryViewを使う場合に綺麗に表示するにはcontentViewにaddSubviewしたほうがいいです。
というかドキュメント通りに基本contentViewにaddSubviewすべきです。

CoreDataのデータを全て削除

(BOOL)resetDatastore
{
    [[self managedObjectContext] lock];
    [[self managedObjectContext] reset];
    NSPersistentStore *store = [[[self persistentStoreCoordinator] persistentStores] lastObject]; 
    BOOL resetOk = NO;

    if (store)
    {
        NSURL *storeUrl = store.URL;
        NSError *error;

        if ([[self persistentStoreCoordinator] removePersistentStore:store error:&error])
        {
            [[self persistentStoreCoordinator] release];
            __persistentStoreCoordinator = nil;
            [[self managedObjectContext] release];
            __managedObjectContext = nil;

            if (![[NSFileManager defaultManager] removeItemAtPath:storeUrl.path error:&error])
            {
                NSLog(@"\nresetDatastore. Error removing file of persistent store: %@",
                  [error localizedDescription]);
                resetOk = NO;
            }
            else
            {
                //now recreate persistent store
                [self persistentStoreCoordinator];
                [[self managedObjectContext] unlock];
                resetOk = YES;
            }
        }
        else
        {
            NSLog(@"\nresetDatastore. Error removing persistent store: %@",
              [error localizedDescription]);
            resetOk = NO;
        }
        return resetOk;
    }
    else
    {
        NSLog(@"\nresetDatastore. Could not find the persistent store");
        return resetOk;
    }
}

半透明のviewを重ねる

半透明のviewの上にviewを以下のように重ねると
子のviewのalphaも親のalphaに引きづられてしまい、子のviewのalphaを1.0に設定してもどちらも半透明になってしまう。

    UIView* view = [[UIView alloc] initWithFrame:CGRectMake(0, 0, 100,100)];

    view.alpha = 0.5;

    [self.navigationController.view addSubview:view];

    

    UIView* childView = [[UIView alloc] initWithFrame:CGRectMake(25, 25, 50,50)];

    childView.backgroundColor = [UIColor whiteColor];

    childView.alpha = 1.0;

これを解決するにはviewではなく、background colorのUIColorのalphaを変える必要がある。

    UIView* view = [[UIView alloc] initWithFrame:CGRectMake(0, 0, 100,100)];

    view.backgroundColor = [[UIColor blackColor] colorWithAlphaComponent:0.5];

    [self.navigationController.view addSubview:view];

    

    UIView* childView = [[UIView alloc] initWithFrame:CGRectMake(25, 25, 50,50)];

    childView.backgroundColor = [UIColor whiteColor];

Objective-Cのクラスメソッドの差し替え

テストのときにUIAlertViewの表示を消してくれるライブラリで
どうやってUIAlertViewのメソッドをフックしてるのかと調べてみたところ
method_exchangeImplementations()を使って実装されてた。

+ (void)swapInstanceMethodsForClass: (Class) cls selector: (SEL)sel1 andSelector: (SEL)sel2 {

    Method method1 = class_getInstanceMethod(cls, sel1);

    Method method2 = class_getInstanceMethod(cls, sel2);

    method_exchangeImplementations(method1, method2);

}








method_exchangeImplementations()を使えばこのようにクラスメソッドを差し替えられるのでテストでは便利。

iOSでKiwiでテストする【基本編２】

つぎはテストコードの中身の書き方です。

it のBlocksの中にテストコードを書きます。

[テスト対象のオブジェクト should] マッチャー:期待される値];

という書き方が基本です。

マッチャーはequalなどですが、詳細はこちらを参照してください。
https://github.com/allending/Kiwi/wiki/Expectations

注意する点としては、
Objective-Cではプリミティブな型(intなど)はオブジェクトではないので、
theValue()で囲ってやることによってオブジェクトにしないとだめです。

SPEC_BEGIN(NSDateSpec)

describe (@"NSDate", ^{
    context (@"When October", ^{
        describe (@"NSDate#lastDate", ^{
            context (@"With year:2012", ^{
                it (@"should be 30", ^{

                        // ここにテストコードを書く
                        NSDate* date = [NSDate dateWithGivenYear:2012 month:10];
                        [[theValue([date lastDay]) should] equal:theValue(30)];
                });
            });
        });
    });

});

SPEC_END

・各テストで共通の前処理、後処理の書き方

以下を必要な階層に入れればよいはずです。

 beforeAll(^{ // Occurs once }); 

 afterAll(^{ // Occurs once }); 

 beforeEach(^{ // Occurs before each enclosed "it" variable = [MyClass instance];     }); 

 afterEach(^{ // Occurs after each enclosed "it" });

・ヘルパーメソッドの書き方

例えばこのような場合青字のところはヘルパーメソッドに置き換えたいといった場合の対応ですが、

SPEC_BEGIN(NSDateSpec)

describe (@"NSDate", ^{
    context (@"When October", ^{
        describe (@"NSDate#lastDate", ^{
            context (@"With year:2012", ^{
                it (@"should be 30", ^{

                        NSDate* date = [NSDate dateWithGivenYear:2012 month:10]; 
                        // 何か処理がいろいろ
                        // ...
                        [[theValue([date lastDay]) should] equal:theValue(30)];
                });
            });

            context (@"With year:1979", ^{
                it (@"should be 30", ^{

                        NSDate* date = [NSDate dateWithGivenYear:1979 month:10]; 
                        // 何か処理がいろいろ
                        // ...
                        [[theValue([date lastDay]) should] equal:theValue(30)];                });
            });

        });
    });

});

SPEC_END

これはBlocksを定義して、呼び出せばよいです。

SPEC_BEGIN(NSDateSpec)

describe (@"NSDate", ^{
    context (@"When October", ^{
        describe (@"NSDate#lastDate", ^{
            //Helper Method.
            NSNumber* (^helpMethodWithCount)(int) = ^NSNumber* (int count) {
                // 何か処理がいろいろ
                // ...
            };            
            context (@"With year:2012", ^{
                it (@"should be 30", ^{

                        NSDate* date = dateWithGivenYear:2012 month:10]; 
                        helpMethodWithCount(100);
                        [[theValue([date lastDay]) should] equal:theValue(30)];
                });
            });

            context (@"With year:1979", ^{
                it (@"should be 30", ^{

                        NSDate* date = dateWithGivenYear:1979 month:10]; 
                        helpMethodWithCount(10);
                        [[theValue([date lastDay]) should] equal:theValue(30)];
                });
            });

        });
    });

});

SPEC_END

^{}で囲まれているところは、そのまんまBlocksなので、その中に値を定義すれば、Blocksから参照できますので、ヘルパーメソッドに限らず定義できます。

iOSでKiwiでテストする【基本編１】

詳細はこちら。
http://www.kiwi-lib.info/specs.html

RSpecのObjective-C実装といったところで、
やはりRSpecと比べるとかなり機能が少なく最小限のようです。

基本的な書き方は、ほぼRSpecと同じなので、RSpecの本とか読めば参考になりそう。


使い方

テンプレートはこんな感じで、

#import "Kiwi.h"

SPEC_BEGIN(Spec名)

describe {@"テスト対象", ^{
    context {@"状態", ^{
        describe @"テスト対象メソッド", ^{
            context @"与える入力", ^{
                it @"期待する出力", ^{
                }
            }
        }
    }

}

SPEC_END
実際に書くと

SPEC_BEGIN(NSDateSpec)

describe (@"NSDate", ^{
    context (@"When October", ^{
        describe (@"NSDate#lastDate", ^{
            context (@"With xxx", ^{
                it (@"should be 30", ^{

                        // ここにテストコードを書く
                });
            });
        });
    });

});

SPEC_END

ちょっと例が悪かったのでインプットが思いつかなかったのですが、、

こんな風に書けばよいはずです。

あとはインプットや状態によって以下のようにテストを増やしていけばいいのです。

SPEC_BEGIN(NSDateSpec)

describe (@"NSDate", ^{
    context (@"When October", ^{
        describe (@"NSDate#lastDate", ^{
            context (@"With xxx", ^{
                it (@"should be 30", ^{

                        // ここにテストコードを書く
                });
            });

            context (@"With xxxxx", ^{

                it (@"should be 31", ^{

                        // ここにテストコードを書く
                });
            });

        });

        describe (@"NSDate#firstDate", ^{
            it (@"should be 1", ^{

                    // ここにテストコードを書く
            }); 
        });

    });

    context (@"When February", ^{

        describe (@"NSDate#lastDate", ^{
            context (@"With xxx", ^{
                it (@"should be 28", ^{

                        // ここにテストコードを書く
                });
            });

    });

});

SPEC_END

なにがよいかというと、テストを実行してみるとわかると思いますが、

出力を見てなんのテストが実行されているのかがわかりやすいのがメリットです。

xUnitでもやろうと思ったらできると思いますが、コピペを繰り返すことになるので、

このように階層構造でわけられるので便利だし、見やすいです。

iphone_dev_jp東京 mac/iphone Hackathonに参加してきた

使えるライブラリを作ろう！というハッカソンに参加してきました。

個人的に家計簿アプリを作っていてNSDateがかなりいけていない（面倒なのが多い）のでそれを楽にするものを作りました。

https://github.com/yanamura3/NSDateHelper

実装自体は自分のソースコードからライブラリ化したいものをひっぱってくるだけだったのでほぼ一瞬で終わってしまい、大半はKiwi使ってテスト書いてました。

できたものはライブラリというかカテゴリになってしまいましたが。

問題はカテゴリを組み込むのにgitsubmoduleやcocoapodsだと２つファイル読みこめばいいだけなのに無駄にプロジェクトファイル毎取り込まなければいけないのがなんだなぁと。この辺りもなにかうまいやりかたを考えていく必要がありそうです。

結構時間があまったのでOCMockitoというモックライブラリで足りない機能があったので追加してみました。

https://github.com/yanamura3/OCMockito

追加したのはスタブのメソッドが呼ばれた際に指定したblocksを呼ぶことができるようにする拡張で、

[given([mock somemethod]) answer:^{ /** 処理 */ } ]

と書けば somemethodが呼ばれるとanswerに渡したblocksが実行されます。

NSProxyのforwardInvocationの勉強にもなったので結構役に立ちました。


最後は発表があったのですが、あまりにもやったことが地味すぎたので
今度ハッカソンに参加するときはもうちょい見た目にインパクトあるものを考えて参加しようと思いました・・・


Togetter
http://togetter.com/li/361912

中島さんの問題

中島聡さんのブログにでていたザッカーバーグの面接試験解いてみました。

問題その１
http://satoshi.blogs.com/life/2012/08/block.html

回答
https://github.com/yanamura3/HTTPLoader

GCDを使って同期リクエストをラップして非同期に見せかけるという一番シンプル（実装の少なくて済む）なやり方で実装で実装しました。
問題としてはキャンセルはできないのでキャンセルもしたい場合は別のやり方のほうがいいです。


問題その２
http://satoshi.blogs.com/life/2012/08/zack2.html

回答
https://gist.github.com/3426890

これはretainカウントを別の用途に使うといった発想でおもしろいやり方だなぁと思いましたが、複数人でやるようなプロジェクトでこういう一見わからない実装を入れると間違った使い方がひょいと混入しそうで怖い感じがします。

Objective-Cのシングルトンパターン

Objective-Cのシングルトンの実装ですが、
GCDにdispatch_onceという便利なのがあるので、これを利用するとすっきり書けますし、dispatch_onceだとXcodeによる補完が強力なので書くのも速いです。
http://stackoverflow.com/questions/7568935/how-do-i-implement-an-objective-c-singleton-that-is-compatible-with-arc


+ (MyClass *)sharedInstance
{
    static MyClass *sharedInstance = nil;
    static dispatch_once_t onceToken;

    dispatch_once(&onceToken, ^{
        sharedInstance = [[MyClass alloc] init];
        // Do any other initialisation stuff here
    });
    return sharedInstance;
}

Objective-Cでprivateなインスタンス変数を外部から変更したり参照する方法

UnitTestなどでテスト対象のクラスのprivateな変数（属性）を参照したり変更したりしたい場合があります。
テストのためにアクセッサを追加したりするのはちょっとあれなので何かいい方法がないか調べてみたらObjective-Cだとテストフレームワークの力を借りるまでもなくあっさりできますね・・

Objective-CのKey Value Codingを利用します。

これはざっくり言うとアクセッサーを用意しなくても、
 setValue: forKeyとvalueForKeyを使えば、名前（Key）でクラスの変数にアクセスできるという代物です。

テスト対象はこのPersonというクラス。（メソッド名がひどいのは無視しましょう）

@interface Person : NSObject

{

@private

    NSString* name;

}

- (NSString*)getName;

@end

@implementation Person

- (NSString*)getName {

    return name;

}

@end

テストコードはこのようになります。

- (void)testName {

    Person * person = [[Person alloc] init];

    

    [person setValue:@"Taro" forKey:@"name"];

    

    GHAssertEqualStrings(@"Taro", [person getName], @"not equeal name");

}

Xcode : TODO, FIXMEなどの記述

TODO, FIXMEなどのコメントを以下のようなフォーマットでつけると
control + 6 でのメソッド一覧の表示の際に#pragma markと同様に簡単に見つけられるようになります。（参考）

// TODO: "comment"
// FIXME: "comment"
// !!!: "comment"
// ???: "comment"
// MARK: "comment"

Xcode4.4以前はメソッドのなかに記載しても表示されませんでしたが、Xcode4.4以降だとメソッドの中に記載しても表示されるようになったのでTODOなどが使いやすくなりました。

Xcode : #pragma markで見出しをつける

プログラム上でたまに見かける　#pragma mark *** 　の使い方です。（参考)

#pragma mark　を使うことでコードをXcodeで見やすくすることができます。
C#知ってる人はC#のpragma regionと似たような感じに使うことができます。（begin-endはいらない）

・書き方
*** のところに何か文字列を記載します。

#pragma mark ***

例：hogeとつけてみる

"control + 6" でメソッド一覧を表示すると
図のようにpragma markでつけたhogeという文字列が一覧に表示されるようになります。

追記：

#pragma mark - ***

とハイフンをつけることで区切り線を出すことができるので更に見やすくすることができます。

たくさんメソッドがある場合などに探しやすくするのによいと思います。

could not locate an NSManagedObjectModel for entity name

"could not locate an NSManagedObjectModel for entity name" というエラーがCoreDataで出た場合の対処方法。

以下のようなコードで、色のついたコードの箇所で止まってしまう場合です。
entity nameはあっているはずなのに・・・と悩んだわけですが、
self.managedObjectContextにちゃんとセットしていないとこのようなエラーがでてしまいます。（エラーの内容が紛らわしい・・）

- (NSFetchedResultsController *)fetchedResultsController

{

    if (__fetchedResultsController != nil) {

        return __fetchedResultsController;

    }

    

    NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init];

    // Edit the entity name as appropriate.

    NSEntityDescription *entity = [NSEntityDescription entityForName:@"Spending" inManagedObjectContext:self.managedObjectContext];

    [fetchRequest setEntity:entity];

iOSでOCMockでテストする【環境構築】

Objective-C用のMockライブラリ　OCMockを使うための環境構築

環境：
　Xcode 4.3.2
   OCMock 2.0

まずここからダウンロード。（ソースコードからやるやり方は後日追記予定）
http://ocmock.org/

"Download"のタブからdmgファイルをダウンロードします。
http://ocmock.org/downloads/ocmock-2.0.1.dmg　(2012/06/24現在の最新）

ダウンロードしたら開きます。
展開されて、iOS, OSX, Source　の３つのディレクトリが現れます。

iOSを開きOCMockのディレクトリをドラックアンドドロップでプロジェクトに追加。

libOCMock.aも同じくプロジェクトに追加。（ここではOCMockディレクトリ内に入れます）

そうするとこのようになるはずです。（注：プロジェクトに追加する際に、Copy items into destination ...にチェックいれるのを忘れないこと)

TargetのBuild Phasesのタブを選択し、Link Binary WIth Librariesのセクションを開きlibOCMock.aを追加します。

#import <OCMock/OCMock.h>を発見できるように、

 Build SettingのHeader Search Pathに$(SRCROOT)を追加。

ライブラリをリンクするために
Build Settingのother linker flagに -ObjC -force_load $(SRCROOT)/OCMock/libOCMock.a　を追加。

以上で環境設定は完了です。

試しにテストコード(SenTest)に

#import < OCMock/OCMock.h>


- (void)testExample

{

    id tableViewMock = [OCMockObject mockForClass:[UITableView class]];

}

を記載して、Cmd + Uでテストを実行してみましょう。

iOSでGHUnitでテストする【環境構築】

GHUnitの環境構築方法です。

環境：Xcode4.3.2

STEP1. プロジェクトの作成

適当にTestGHUnitというプロジェクトを作ります。

STEP2. GHUnitの取得

２つの方法があります。git使っている人や男気があるひとは後者を使うといいと思います。

方法その１．
ビルドされてるのをそのまんまつかう。

https://github.com/gabriel/gh-unit/downloads　からGHUnitIOS ***.zipをダウンロードしてくる。（上のほうの新しいやつのほうがいいと思います. 0.5.2で確認）

解凍するとGHUnitIOS.frameworkというフォルダができているので
プロジェクト内のフォルダに保存。

ここではTestGHUnitの下にFrameworksというフォルダを作成してその中に入れておきます。

TestGHUnit/Frameworks/GHUnitIOS.framework

方法その２．
githubからソースコードをとってきて、自らビルドする。
メリットとしてはgitですぐに最新版にアップデートできる点。

$ cd TestGHUnit/
$ ls
TestGHUnit TestGHUnit.xcodeproj TestGHUnitTests
$ mkdir Frameworks
$ cd Frameworks
$ git submodule add https://github.com/gabriel/gh-unit.git
Cloning into gh-unit...
remote: Counting objects: 7028, done.
remote: Compressing objects: 100% (2426/2426), done.
remote: Total 7028 (delta 4687), reused 6667 (delta 4360)
Receiving objects: 100% (7028/7028), 39.60 MiB | 268 KiB/s, done.
Resolving deltas: 100% (4687/4687), done.
$ cd gh-unit/Project-iOS

makeします

$ make

makeしたら以下のようなエラーがでる場合があります。

Error: No developer directory found at /Developer. Run /usr/bin/xcode-select to update the developer directory path.

Xcode4.3からXcodeのパスが変わっているためxcode-selectで/Developerのほうを見に行ってミスっている

$ sudo xcode-select -switch /Applications/Xcode.app/Contents/Developer

で治る

STEP3. ビルドセッティング

まずテスト用のターゲットを追加します。

プロジェクトセッティング画面を開いて左下のAddTargetボタンを押し、EmptyApplicationを選びます。

ProjectNameを適当にUnitTestなどとします。

Use Core Dataや　Include Unit Tests などにはチェックいりません。

次にTARGETSのな家から作成したUnitTestを選択し、BuildPhasesの画面を出します。

Link Binary With Librariesのセクションを開き下の＋ボタンを押してフレームワークを追加します。

下のAdd Otherを選択します。

ビルドしたものをダウンロードした場合はTestGHUnit/Frameworks/GHUnitIOS.frameworkのフォルダを選択してOpenを押す。

自前でビルドした場合は、gh-unit/Project-iOS/build/Framework/GHUnitIOS.frameworkを選択。

そうするとこうなるはず。

もしも別の表記になっていたり、アイコンが違ったりしたら - ボタンを押して一回消してから上のをやり直すと治ったりします。

次にBuild Settingを開き、Other Linker Flagに -ObjC -all_load を追加します。

これでテストを書けば動く状態になっているはずです。

STEP4.　テスト

UnitTestのフォルダ内のAppDelegate.h(ここではYYAppDelegate.h)を消します。

そしてYYAppDelegate.m を以下のように変更

#import <GHUnitIOS/GHUnit.h>

@interface MyTest : GHTestCase {   

}

@end

@implementation MyTest

- (void)testStrings {

    NSString *string1 = @"a string";

    GHTestLog(@"I can log to the GHUnit test console: %@", string1);

    

    // Assert string1 is not NULL, with no custom error description

    GHAssertNotNULL(string1, nil);

    

    // Assert equal objects, add custom error description

    NSString *string2 = @"a string";

    GHAssertEqualObjects(string1, string2, @"A custom error message. string1 should be equal to: %@.", string2);

    GHAssertEquals(1, 1, @"test");

}

- (void)testNums {

    GHAssertEquals(1, 2, @"test");

}

@end

main.m を以下のように修正

        return UIApplicationMain(argc, argv, nil, @"GHUnitIOSAppDelegate");

そしてテストを実行。

UnitTestのiPhone Simulatorを選んで、　Runボタンを押せば完了です。

iOSでKiwiでテストする【環境構築】

Kiwiのドキュメントや他のサイトでも手順があったわけですが、そのままだとちょっとうまくいかなかったのでまとめておきます。(具体的にはKiwi.hのパスを通すところ）

　　環境　：　iOS4.3.2
　　Kiwi　：　 commit 04bf281d35f4cee2c763bfca5c196fdb75b28b36

まず適当にプロジェクト（TestKiwi）を作成します。（SingleViewApplication）

include Unit Testsにはチェックを入れておきます

プロジェクトの作成が終わったら、Cmd + Uでテストを実行すると失敗しますがこれでOKです。（テストでひっかかっているところはとりあえずコメントアウトしておきます）

次にKiwiを取得します。手動でダウンロードしてきてもいいですが、Kiwiが更新されたときの同期を楽にするためにgit submoduleを使っておきます。

$ cd TestKiwi

$ ls

TestKiwi TestKiwi.xcodeproj TestKiwiTests

$ mkdir Frameworks

$ git submodule add https://github.com/allending/Kiwi.git Frameworks/Kiwi

Cloning into Frameworks/Kiwi...

remote: Counting objects: 1627, done.

remote: Compressing objects: 100% (556/556), done.

remote: Total 1627 (delta 1035), reused 1592 (delta 1010)

Receiving objects: 100% (1627/1627), 12.65 MiB | 297 KiB/s, done.

Resolving deltas: 100% (1035/1035), done.

$ ls Frameworks/Kiwi/

Classes Kiwi.podspec Other Sources Templates

Examples Kiwi.xcodeproj Readme.md Tests

Kiwi License.txt Resources install-templates.sh

下記コマンドでKiwiのディレクトリを開いてKiwi.xcodeprojをどラックランドドロップでXcodeの左の枠内のTestKiwiTestsのディレクトリに持っていきます。

$ open Frameworks/Kiwi

そうすると下のようになるので、Kiwiのテスト用のファイルを追加していきます。

中身が空のObjective-Cのファイルを作りたいのでEmptyで作ります。

適当にKiwiSpec.mという名前で作成します。（写真では.mが抜けているので注意）

下のTargetにTestKiwiTestsがチェックされていることを確認。

KiwiSpec.mに#import "Kiwi.h"　を記載して、Cmd + U を実行するとエラーがでます。

Build SettingのHeader Search PathにFramework/Kiwiを追加

再びCmd + U でまだエラーがでます。

HeaderSearchPathに Frameworks/Kiwi/Classes　を追加

これでめでたくビルドが通ります。

KiwiSpec.hにテストコードを記載し、Cmd + Uするとまたたくさんエラーが。

まずProjectの設定画面をひらいてTargetのTestKiwiTestsを選択し、Build PhasesのTarget DependenciesにKiwiを追加します。

Link Binary With LibrariesにlibKiwi.aを追加。

 そしてBuid Settingsに移動して、 Other Linker Flagsに -all_load を追加。

 これで　Cmd + U でビルドが通るはずです。