I found it:
Though the tableViewController was instantiated via storyboard etc., the view had not been loaded yet!
So viewDidLoad
also had not been called yet, when I 'changed' my model. But then, when I called [_sut.tableView reloadData]
(which should make sure, the tableView would get synced with my model), this caused exactly the opposite: accessing the tableView made it necessary that the view got loaded, so NOW finally viewDidLoad
was called on my tableViewController! And so my model got changed again, overwriting my nice test model with default values.
The solution was, to add [_sut view];
to the top of my test case. This makes sure that the view is already loaded when my test begins.
And, in my case, calling [_sut.tableView reloadData]
wasn't necessary at all, since I'm only testing the dataSource method directly, not the actual tableView. N.B.:[_sut view]
still needs to be called, because the dataSource method in my XCTAssertEqual() statement also triggers the view to be loaded, if that has not happened yet.
So the working test case looks like this:
- (void)testTwoStoriesShouldLeadToTwoRowsInSectionZero
{
[_sut view];
_sut.sortedStories = [self arrayWithTwoStories];
XCTAssertEqual([_sut tableView:_sut.tableView numberOfRowsInSection:0], 2, @"The number of rows should match the number of stories");
}