Toby's first few days

During his brief 'vacation' from work, Toby got a chance to do some reading and is psyched to try out a few new ideas with what he already knows. After getting through the first boring day of employee training, he arrives the next morning and starts planning. Not completely sure if he understands everything the multitude of Access databases handles, he spends the rest of the day chatting with the other groups who use the system.

After a relaxing evening at home and finishing Evans' DDD book, the next day he fires up Darkroom and writes:

The company is always working on a set of projects. Each project consists of many jobs and a job can have one or more drawings. A drawing can have multiple versions, each of which must be tracked separately. There are several departments in the company who can receive a copy of the drawing and it's important to know when (and if) they received it.

Pleased with his ability to perfectly mimic something he's just seen, he wonders what to do next. Toby prides himself on being an agile developer, but being the only person around he's tempted to start 'prototyping'. Since his boss hasn't yet given him a deadline for the system upgrade and he's itching to fire up Visual Studio, Toby decides to forego writing any user stories for now.

After creating his Object Model class library project, codenamed 'Grimlock' (Toby has been a Transformers fan for quite some time), he adds the required NUnit dependencies and dives in.

A drawing requires a job number, so creating a drawing without one should fail. Chances are there will be some kind of JobId in future, but for now we'll just leave it as a string. The same rules apply to drawing id and title. He then adds a revision property and soon has a first version of the Drawing class fleshed out. By now it's lunchtime so Toby goes to eat with his co-workers.

        [Test]
[ExpectedException(typeof(ArgumentException))]
        public void CreatingDrawingWithNullJobIdThrows()
{
            Drawing d = new Drawing(null, "drawing", "title");
}

[Test]
[ExpectedException(typeof(ArgumentException))]
        public void CreatingDrawingWithEmptyJobIdThrows()
{
            Drawing d = new Drawing("", "drawing", "title");
}

<snip> ...

        [Test]
        public void CanCreateDrawingSuccessfully()
{
            Drawing d = new Drawing("job", "drawing", "title");

            Assert.IsNotNull(d);
            Assert.AreEqual(d.JobNumber, "job");
            Assert.AreEqual(d.Number, "drawing");
            Assert.AreEqual(d.Title, "title");
}

[Test]
        public void ByDefaultDrawingHasNoRevision()
{
            Drawing d = new Drawing("job", "drawing", "title");

            Assert.IsFalse(d.IsRevision);
}

In the afternoon, he quickly runs through the other major classes (Project and Drawing) and decides to try his hand at some sort of storage mechanism. Unsure what database the current budget will allow for, he decides to stick to a simple abstraction for now. The word 'repository' is still ringing in his ears from the previous night's reading so back into VS he goes. Fifty-three tests later, this is the state of the world:

After finishing his classes he feels something is a bit odd, but decides to call it a day. He's not convinced that he really understands why he wrote the repository classes and is having second thoughts about following a book blindly.  

Toby's code can be found here.

Comments

• Anonymous
  June 20, 2007
  A colleague of mine was reading through Toby's adventures and asked why, in the name of all that is good,