CalendarDayView: Initial Design Specs and Setup
I've come up with some preliminary design specs of the initial functionality that I want in this control. I've included some of the interactions that can happen in the control, and the basic view (once I figure out how to attach an image, I'll make that available on this post). I want to recreate the Outlook style single day view functionality, while making it functional in a rich AJAX sense. With a TDD approach, I'll create a series of unit tests to test the server-side functionality, and I'll have to come up with some sort of client-side test functionality. To test the client-side functionality, I've seen others develop their own utilities for testing (test harnesses) to test the client-side rendering.
I'm really excited about a new technology coming out nicknamed Ivonna. This framework allows you to test ASP.NET pages at a server-level, which is something that wasn't always easily done before. I can't wait for this to be fully developed. If you haven't heard of TypeMock Isolator, TypeMock is a very powerful tool that allows you to mock objects, the results returned from it's properties and methods, and even affect the path that the code takes. It's really dynamic in how it works, and what makes it really great is that it isn't dependent on interfaces; it can mock any object, unlike other mock frameworks.
With that said, I'm also glad that I should be able to utilize ExactMagic TestMatrix to perform my tests; TestMatrix allows me to compile and run my tests directly in Visual Studio, without having to run NUnit. It also provides code coverage to show me what code wasn't executed through my unit tests. This makes unit testing a lot easier.
In addition, a calendar often works with scheduling items; I do already have a framework in place for scheduling events, which is very similar in nature. I'm going to try to reuse this code, instead of recreating new code, and we'll see as we get into it. I may try to minimize the cost by creating a little bit of abstraction to hide those details. I hope that my posts will be informative and help you in some way understand TDD, agile, and control development.
To start off requirements gathering, I mentioned about a couple of sketches, but really it should start off from a series of stories. Some of the stories for this project include:
- User can view their calendar day.
- User can add new entries to the calendar day.
- User can scroll up and down the calendar day view.
However, some sources recommend a more formal story approach, as shown below:
- As a developer, I want to configure the time interval, so I can change the way the calendar renders.
- As a user, I want to be able to click in the calendar time slot, so I can create a new entry.
- As a user, I want to be able drag the appointment date to expand the time, so I can adjust the appointment.
You can find some examples of stories here:
I'm not going to go to the point of performing an estimation, because I am not able to put consistent hours into this that it will be harder to track, but for each story, a level of difficulty and a priority is assigned to it; the priority is assigned by the customer, and from the difficulty or risk level is assigned by the developer. This is what specifies priority.