0

I'm digging myself into TDD and startet using SenTestingKit along with OCMock. I'm using FMDB as a wrapper for my SQLite Database.

I can't get my head around how to mock the DatabaseQueue class, so it correctly invokes the invocation block with an FMDatabase object.

Any ideas?

CustomerFactory.h

@interface CustomerFactory

// DatabaseQueue inherits from FMDatabaseQueue
@property (nonatomic, retain) DatabaseQueue *queue;

- (id)initWithDatabaseQueue:(DatabaseQueue *)queue;

@end

CustomerFactory.m

@implement CustomerFactory

- (id)initWithDatabaseQueue:(DatabaseQueue *)queue
{
    if ((self = [super init]))
    {
        [self setQueue:queue];
    }
}

- (NSArray *)customersByCategory:(NSUInteger)categoryId
{
    __block NSMutableArray *temp = [[NSMutableArray alloc] init];

    [self.queue inDatabase:^(FMDatabase *db)
    {
        FMResultSet *result = [db executeQuery:@"SELECT * FROM customers WHERE category_id = ?", categoryId];

        while ([result next])
        {
            Customer *customer = [[Customer alloc] initWithDictionary:[result resultDictionary]];
            [temp addObject:customer;
        }
    }];

    return temp;
}

@end
Christoph Winkler
  • 6,278
  • 1
  • 18
  • 18

1 Answers1

1

If you are testing the CustomerFactory class, then you should not do it at all. Think about it as testing the interface of our unit, which is a CustomerFactory instance. You have the method called customersByCategory: and you are only interested in getting the NSArray of your customers object from this call. The fact that you use the DatabaseQueue and FMDatabase instances inside is the implementation detail which should be transparent to this specific unit test.

Testing the DatabaseQueue class is a different story, but it looks like the easiest way to achieve what you want is to use a real instance of the DatabaseQueue in your test.

lawicko
  • 7,246
  • 3
  • 37
  • 49
  • But this would require a filled Database to test. I managed to get it working but my test is horrible long. I'm thinking of refactoring it, so it's easier to test. Will update my Question tomorrow at work. I want to test as many code without integration tests. – Christoph Winkler Feb 19 '13 at 20:15
  • I think your **DatabaseFactory** class depends on the FMDatabaseQueue too much and testing it as a separate unit wouldn't really make sense unless you have a test database against which you can run this kind of unit test. – lawicko Feb 19 '13 at 22:14