Dealing with implementation concerns in TDD

I've just got started on TDD and very quickly ran into a brick wall. Her开发者_运维技巧e's my scenario... I'm trying to model an Image object, and going through the TDD steps I've started with a simple object which eventual grew into...

public class ImageObject
{
 public string Name {get; set;}
 public int Width {get; set;}
 public int Height {get; set;}

 public bool IsValid()
 {
  //Some rules
 }
}

Of course the obligatory tests...

[Test]
public void ImageWidthCannotBeLessThanZero {...}
[Test]
public void ImageHeightCannotBeLessThanZero {...}    
and so forth...

So far so good. Next, I want to represent the physical file in the class somehow. It could be with a file path

public class ImageObject
{
  public string Path {get; set;}
}

or a series of bytes

public class ImageObject
{
  public byte[] Bytes {get; set;}
}

(Please this is not an argument about DB vs File system for storage.)

At this point I'm not feeling comfortable because my mind is drifting and starting thinking about the infrastructure/implementation details. Where is my flaw?? Should i make the decision upfront on the implementation detail? Do i need a clever design pattern to deal with this? Would a mocking framework help? This is an Object Analysis/Design problem and I should use UML tools? (Wait a minute i thought TDD was about design?)

Anyway how do i overcome this of problem? I want to remain focused on designing my objects and not think about infrastructure concerns at this time?

I think you could be starting in the wrong place. You say 'Next, I want to represent the physical file in the class somehow' - why? What test is failing which has lead to the need to represent the physical file?

One issue is that you're exposing the representation through a public property - is this really what you want to do? Or can the physical representation be kept private, with access only via some operations you chose to implement (e.g. 'LoadImage()', 'GetImageBytes()')? If it's kept private, it shouldn't matter to your tests what the implementation is.

In TDD, the class being developed shall be considered with an outside-in perspective. Where does the image comes from ? What do you intent to do with the image ? display it ? send it over a network ? apply some transformation to it ? insert in into a gallery ? The answers will give the direction to follow. And the next test to write. The tests shall guide the design, not what an Image class could be.

Indeed, for drawing application, a gallery generator or an email reader, the ImageObject will be different as the class that will use this class have different needs.

You are focusing too much on modeling that class, instead of implementing an actual scenario.

imho that's a big difference in how to tackle the problems when you use TDD.

This is what keeps you from adding unnecessary elements to the classes, and makes you go toward simpler designs with less upfront analysis time.

Focus on the scenarios you need to implement. Let that drive your needs for these classes and what you need in there.