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.

« Continue »

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.

Last week, I wrote about techniques to find a list of the .NET assemblies that xUnit.net needs to run unit tests. To review:

• When Visual Studio compiles a unit test project, it doesn’t copy all of the required dependencies into the output directory.
• Therefore, we need a way to manually find these dependencies.
• To find the dependencies, we can attempt to run unit tests and look for detailed error messages. One messages is shown when a FileLoadException occurs. Another one is found in Assembly Binding Log Viewer output: “All probing URLs attempted and failed.” Using these messages, we can manually copy dependencies to the unit test project output directory.
• If these debugging techniques uncover the need for two or more assemblies with different versions, binding redirection can be used to define a single version to use.

Missing dependencies prevent Visual Studio from discovering unit tests (i.e., finding them so they can be listed in Test Explorer). Using these debugging techniques, we should be able to successfully discover all of the unit tests in a project. The next step is to try to run the discovered tests.

« Continue »

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.

As I mentioned last week, I’m working on a backlog of unit tests, and have run into a problem involving NuGet package dependencies. Copying DLL dependencies has been an ongoing issue with unit tests. Until now, I have been fixing problems as they come up, sometimes by trial and error. But I decided it’s time to write a more comprehensive explanation.

« Continue »

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.

Having finished a basic end-to-end idle time feature, I find myself with a bit of a unit test backlog.

Programmers can debate about when to write tests. But in my experience with Time Tortoise, there are times when experimenting first and writing tests later is the only realistic option. During these times, there are already too many technical issues to figure out without throwing testing in the mix as well. That was the case with the recent Time Tortoise Companion work. But now it’s time to pay off the unit testing debt and get back to full coverage.

« Continue »

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.

After several weeks of infrastructure work, it’s finally time to make the idle time feature available in the Time Tortoise UI.

« Continue »

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.

A practical time tracker needs to take into account user idle time, but it isn’t possible to do that using UWP. So for the past few weeks, I have been working on a companion app that will provide the main UWP app with information, like idle time, that it can’t get on its own. The SignalR-based communication infrastructure is now done, so this week I worked on the idle time detection.

« Continue »

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.

Last week, I covered the reason for using SignalR in Time Tortoise, and how SignalR can be used to build a simple chat application. This week, I’ve been working on integrating minimal SignalR functionality into the Time Tortoise codebase.

« Continue »

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.

To communicate with its companion app, Time Tortoise needs to use sockets. In recent weeks, I have been experimenting with socket communication between a UWP client app and a server running in a console app. This architecture works when everything is set up and running as intended. But it can be tricky to make sockets robust. So this week I’m looking into adding a layer that makes sockets easier to use and more resistant to unexpected failures.

« Continue »

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.

To build a companion app that implements functionality that a UWP app can’t, it’s necessary to pick a non-UWP technology to use. Here are a few options:

• A Windows service: Since the Time Tortoise Companion App only needs to send messages to and receive messages from Time Tortoise, it may not require a user interface. A Windows service allows code to run in the background on Windows, without a UI. I have a couple of concerns with this approach: 1) It’s a bit unfriendly, especially for users unfamiliar with Windows services, to have a mysterious service running in the background; and 2) I may find a need for a companion app UI in the future. This is not in itself a good enough reason to avoid the Windows service approach, but it’s a strike against it.
• A Windows Forms app: This solves both of the concerns with the Windows service. But there’s no reason to use this ancient UI framework for a brand new app, when there are other options available.
• A Windows Presentation Foundation app: WPF isn’t as cutting-edge as UWP, but it uses the same UI markup language (XAML). And since it is widely used, it’s likely to support any functionality that I need. So that’s what I’m going with for the companion app.

« Continue »

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.

Last week, I brought up some limitations of UWP apps, including one that will affect Time Tortoise. I also suggested the idea of a companion app that could address these limitations. This week, I’ll start exploring the companion app in more detail.

« Continue »