In the current Cocoa app I'm working on, I've got an object,
RecordScheduler, which responds to two types of notifications, "day did pass" and "quicksaving interval did pass". In both cases, the
RecordScheduler tells a
Recorder to do its recording job, among other things.
Now I want
RecordScheduler to issue a recording when the Mac goes to sleep.
You subscribe to sleep/wake notifications via
[[[NSWorkspace sharedWorkspace] notificationCenter] addObserver:self selector:@selector(computerWillSleep:) name:NSWorkspaceWillSleepNotification object:nil];
This is easy enough. Add it to
-init and the notifications would be processed just nicely.
Thing is, for the other two cases I wrote helper methods like
fireDayDidPass() to use in unit tests. I fired my custom notifications and added assertions for
RecordScheduler's response. Works well. I don't feel comfortable firing a
NSWorkspaceWillSleepNotification since (a) it's not my own, and (b) I don't know about any side effects.
Instead, I resorted to calling
[scheduler computerWillSleep:nil] which would receive notifications. Now I don't have an intergration-ish test to verify
RecordScheduler subscribes to
After I found out there is no additional information to be sent, I abandoned the idea of creating a
HibernationObserver which subscribes to
NSWorkspace's notifications and re-sends my own kind of "Will Sleep" and "Did Wake" notifications. There seemed to be no additional benefit.
Now here's the point:
- Is it still a unit test when I fire a notification and assert for both the side effects of notification handling and the receiver's subscription upon initialization?
- How else could I verify an object signs up itself as a notification receiver?
- Should I make it a habit to wrap system notifications in my own?