Databases
StackOverflow2013
Postsdbo
POTesting controller method with OCMock and Core Data
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POTesting controller method with OCMock and Core Data
    primarykey
    data
    text
    <p>I am just grasping the concepts of TDD and mocking, and am running into an issue in terms of how to properly. I have a sheet that drops down and lets a user create a new core data object and save it to the data store. I am not sure if I am taking the best approach to testing it.</p> <pre><code>- (IBAction)add:(id)sender { NSString *itemName = [self.itemNameTextField stringValue]; SGItem *newItem = [NSEntityDescription insertNewObjectForEntityForName:kItemEntityName inManagedObjectContext:[self managedObjectContext]]; newItem.name = itemName; NSError *error = nil; BOOL canSaveNewItem = [[self managedObjectContext] save:&amp;error]; if (!canSaveNewItem) { [NSApp presentError:error]; } [self clearFormFields]; // Private method that clears text fields, disables buttons [NSApp endSheet:[self window] returnCode:NSOKButton]; } </code></pre> <p>I'm trying to write two test methods to test this: one that tests the scenario where the managed object can't save and one where it successfully saves. </p> <pre><code>@interface SGAddItemWindowControllerTests : SGTestCase { @private SGAddItemWindowController *addItemWindowController; id mockApp; id mockNameField; } - (void)setUp { mockNameField = [OCMockObject mockForClass:[NSTextField class]]; mockApp = [OCMockObject mockForClass:[NSApplication class]]; addItemWindowController = [[BLAddItemWindowController alloc] init]; [addItemWindowController setValue:mockNameField forKey:@"itemNameTextField"]; } - (void)testAddingNewItemFromSheetFailed { // Setup NSString *fakeName = @""; [[[mockNameField expect] andReturn:fakeName] stringValue]; [[mockApp expect] presentError:[OCMArg any]]; // Execute [addItemWindowController add:nil]; // Verify [mockApp verify]; } - (void)testAddingNewItemFromSheetSucceeds { // Setup NSString *fakeName = @"Item Name"; [[[mockNameField expect] andReturn:fakeName] stringValue]; [[mockApp expect] endSheet:[OCMArg any] returnCode:NSOKButton]; // Execute [addItemWindowController add:nil]; // Verify [mockApp verify]; [mockNameField verify]; } @end </code></pre> <p>Here are the issues I know I have, but am not sure how to work out:</p> <ol> <li>I am not sure how to handle dealing with the managed object context in terms of the test. Should I bring up the entire core data stack or just create a mock of <code>NSManagedObjectContext</code>? </li> <li>The idea of just setting the text field values as the way to trigger the if statement seems wrong. Ideally I think I should stub out the <code>save:</code> method and return YES or NO, but given question 1 I'm not sure about the Core Data aspects of it all.</li> </ol> <p>I think I'm on the right track, but I could use a second opinion on how to tackle my issues and set me on the right path for testing the code snippet. </p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USJustin Williams
    1. USJustin Williams
    plurals
    1. This table or related slice is empty.
    1. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POTesting controller method with OCMock and Core Data
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POTesting controller method with OCMock and Core Data
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POTesting controller method with OCMock and Core Data
      1. This table or related slice is empty.
      1. VTUpMod
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload