Now that we’ve got part of our Project API down, now, we need to use that to calculate a projected completion date. The requirement is to calculate the project’s end date based on the number of tasks finished in the last three weeks. Appropriate the agile term “velocity” to describe the rate of task completion. To make this work, we need to distinguish between tasks that concluded in the last three weeks and tasks that did not.

That means we have to deal with dates.

Date and time programming problems

Programming with dates and times can be annoying… Time is especially problematic in testing because tests work best when each test run is identical. However, due to the universe’s nature, the current time inexorably changes from test run to test run. This can lead to all kinds of problems, including tests that fail on or after a particular day or tests that pass only at certain times of the day. It would help if we tried to avoid all of that.

Getting started with date and time

We’re testing bottom-up, so it’s a good idea to start at the smallest unit of code we can think of. In this case, that’s having Task instances to be aware of whether they have been completed in the three-week window.

We’ll present the entire set of Task tests in the interest of not showing every tiny step this time around. A task completed in the last three weeks counts toward velocity, which implies two negative cases:

  • An incomplete task
  • A task that was completed long ago

To be clear, we wrote and passed them one at a time, but we don’t need to walk through all those steps a second time. Once again, we’ve wrapped the existing code in a describe block, and we are adding the new specs as their own describe block.

Get hands-on with 1400+ tech skills courses.