I'm attempting to try out using unit test in for the first time in new iOS activity for work. I love the idea of unit testing, but always find the specifics to be... messy.
I get the general principals -- I have read a lot about it so I wanted to ask a specific question.
I have a UITableView that can have anywhere from 10 to 10,000 items. I would like to do partial loading. Load the first 100 or so, and then when the user scrolls down half way, load the next 100. Or something like that.
My calls to the DB are asyc (I do not control this, although I guess I could block and wait on the main thread if I really wanted to).
My first thought is to have an NSMutableArray and a function to load/update the data in my UIViewController. I also need to keep track of if the data is finished loading and if the data is currently being reloaded (because it's an async call). However, I'm wondering if it's better to split this into its own class for testability? Let's call it SmartMutableArray?
My concerns are
- If I do this, it requires more selectors then before. I already need to create a call back for my call to the database, and now I need to create another one for my UIViewController to be notified when SmartMutbleArray is completed loading. I would think this makes my code harder to read.
- Because my new array is updated in the background, I think I need to use
self performSelectorOnMainThread:@selector(addObjectsFromArray:) withObject:response.balances waitUntilDone:YES];to update the new array in my new SmartMutableArray class. Which seems weird to me, that this class needs to know it's a data source for a UI element.
- If I don't break it up, I have to test all this loading indirectly by calling my UITableView delegate commands.
I've plowed ahead with creating the new class for this list... but I'm curious what people with more experience think of something like this. Is it overkill?
Thanks for any input, sorry for the length. Please let me know if I'm missing any details that would be useful though.