Time Tortoise: Time Segments in the UI

Time Segments 2

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.

Earlier this month, I wrote about time segments, a fundamental part of time tracking. In that article, I described the implementation of the database schema, model, and view model for time segments. This week, I’ll be focusing on the user interface.

« Continue »

Time Tortoise: Visual Studio 2017 Upgrade

VS2017

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.

Two weeks ago, Visual Studio 2017 officially launched. Although preview and release candidate versions of VS2017 have been available for almost a year, I have until now been conservatively using VS2015 for my project. But I decided that now is the right time to upgrade. Time Tortoise is still quite small, but it’s getting bigger. And although it can be tricky to work with new tools, VS2017 has had quite a bit of community testing, so I’m not too worried.

Here’s what I found during the upgrade process, which took place over the past week.

« Continue »

Time Tortoise: Time Segments

Time Segments

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.

The most fundamental pieces of a time tracker are activities and time segments. Activities are the things you’re working on, and time segments are the times throughout the day when you work on them. I’ve been discussing the implementation of activities for the past few weeks. This week, I’m starting on time segments.

« Continue »

Time Tortoise: Three Test Topics

Console

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.

One of the preconditions for using test-driven development is a willingness to spend time figuring out how to test your project in an automated way. Just as research and experimentation is required to get your program to do what you want, TDD requires research and experiments that lead to test code.

This week, I have three test topics: testing UI behavior without a UI, using a console application for testing, and testing time-related features.

« Continue »

Time Tortoise: Code Coverage

Code Coverage

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 key part of test-driven development (TDD) is writing unit tests first, and then writing the code that makes them pass. The benefits of the test-first approach, as explained in an Extreme Programming article from 2000, are still relevant 17 years later:

  • You don’t have to make time to write tests later (assuming you remember to write them later).
  • You have to understand the requirements before you write the code.
  • You know when you’re done writing each section of code (because the tests pass).
  • You’re less likely to build functionality that you don’t need, since writing each test makes you think about the value of the use case that you’re implementing.

These are all real benefits, and test-first is a good approach in many cases. However, there’s a common scenario where it’s difficult to follow test-first strictly. Consider my Time Tortoise project. Since I’m making up my own requirements, it’s easy to come up with use cases and think about what tests I should use to verify them. But some tests need to call low-level methods, so they require a clear understanding of the technology stack. If you’re learning a new technology (as I am with UWP), you may need to experiment with several ideas before you know what kind of code will be required to implement a use case. When you’re in that phase of your solution development, it may not make sense to follow the test-first approach.

Here are some examples from my Time Tortoise work this week.

« Continue »