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 »

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 »

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 »

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 »

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.

Incremental Build Model

Last week I made my first commit to the GitHub repository for Time Tortoise, the app that I’m working on this year.

I publish a blog post every Wednesday, so I have adopted that schedule for this project as well. In general, each blog post is associated with a GitHub commit. In the first few weeks of the year, I used example UWP projects to experiment with a few ideas. Starting last week, my commits have been adding functionality to the Time Tortoise app itself.

This approach is an example of the incremental build model of software development. The idea is to start with a small working program and build it over time through a series of small (incremental) improvements. After each increment, the program remains usable, and it has slightly more functionality.

In agile terms, I’m building Time Tortoise using a series of one-week sprints, with a release at the end of each sprint. Since the project team consists of one very part-time developer (me), the scope of each sprint is small. But thanks to the incremental build model, it will add up to something useful over time.

The scope for this week: create, update, and list activity names.

« Continue »

Since the beginning of the year, I have been doing some research for a project related to time tracking. As part of the research, I build a tiny sample app to try out the technology stack that I’ll be using.

This week, I’m making my first few commits to the GitHub repository that I’ll be using for the real app. The app also now has a name, Time Tortoise, and a logo, the stern-looking creature at the top of this post.

« Continue »

Last week, I wrote about the basics of unit testing UWP apps, including steps required to get xUnit.net and code coverage working together. This week, I’ll cover a few more unit testing topics related to testing components in isolation. That will wrap up the UWP example app that I have been building over the last few weeks.

« Continue »

Before I start actually building my time tracking app, I have one more topic to cover: unit testing. I’ll tackle it in two parts, one this week and one next week.

« Continue »

This year, I’m building a UWP time tracking app. Last week, I covered some details about Model-View-ViewModel, a pattern that helps simplify user interface code and make it more testable. This week, I’m going to explore the data layer technologies that I’ll be using: Entity Framework and SQLite.

« Continue »

Last week, I covered the solution stack that I’m using for a new programming project. This week, I’ll go into more detail about one aspect of it: using the Model-View-ViewModel (MVVM) pattern in Universal Windows Platform (UWP) apps.

« Continue »