This is one in a series of articles about Time Tortoise, a Universal Windows Platform app for planning and tracking your work schedule. For more on the development of this app and the ideas behind it, see my Time Tortoise category page.
I’m in the process of resolving a unit test backlog for the Time Tortoise idle time feature. Last month, I explained why it’s acceptable in some situations to delay writing unit tests. I also covered a couple of unit testing best practices: interface-based design and minimizing the size of code-behind classes.
Over the past two weeks, I covered some challenges related to .NET assembly dependencies.
This week: more details on the idle time unit tests.
When User is Idle, Idle Timer Starts
The most basic idle time test scenario is this: when the user is idle, the idle timer starts. It sounds simple, but testing it requires a bit of unit test infrastructure.
Mock time
To unit test any scenario involving time, it’s important to avoid depending directly on System.DateTime, since you have no control over what the Now property of that type returns. That’s because it uses the system clock, so the test would have to depend on what the time happened to be when the test was running. This would make it difficult to test specific scenarios.
Instead, we want to depend on an IDateTime that can be mocked. For the current test, we’ll need an idle start time, idleStartTime and an idle end time, idleEndTime: the time range that the user is away from their computer. We can use Moq to ensure that methods return one of those times, as required by the test. In particular, we want Now to be idleEndTime, and we want the user’s last recorded activity to occur at idleStartTime.
Mock SignalR client
Because of the limitations of UWP, Time Tortoise can’t read the user’s idle time directly, so it receives it from Time Tortoise Companion (TTC) via SignalR. But in a unit test, we don’t want to rely on the assumption that TTC is running. So we need a mock TTC. Or more specifically, we need a mock SignalR client that pretends to be receiving messages from TTC.
As with the DateTime example, we can accomplish this by avoiding any direct dependencies on the SignalR client, and instead depending on an ISignalRClient interface. We can then use Moq to make it return the results we need.
The SignalR client exposes a queue of date/time messages that is updated whenever TTC detects activity from the user. So the last message in the queue stores the time of the user’s last recorded activity. If we make sure this time is idleStartTime, then the test preconditions will be satisfied.
The main page view model has a method called CheckIdleTime that is called on a timer in the application code. Since we don’t want timers in unit tests, we can just call it directly in the test. This method dequeues a message from the message queue and interprets it as the user’s last activity time. There are a number of things we can check to ensure that its interpretation is correct, but for this first test it suffices to check that the idle time segment start and end time are correct. If this is the case, we know that the idle time section of the user interface will also show the correct values.
Remaining Idle Time Tests
With this design in place, it’s relatively easy to write a few more tests and cover 100% of the idle time code. Here are the ones I came up with:
- After the first idle check, ensure that the idle timer maintains correct start and end times in subsequent checks.
- Ensure that if the user is not reported as idle, the idle timer doesn’t start.
- When the user clicks the Include button, ensure that timing stops and that the most recent time segment ends at the idle end time (i.e., including the idle time period).
- When the user clicks the Exclude button, ensure that timing stops and that the most recent time segment ends at the idle start time (i.e., excluding the idle time period).
(Image credit: Ted Major)