Работа с проблемами реализации в TDD

Question

Я только начал работать с TDD и очень быстро столкнулся с кирпичной стеной. Вот мой сценарий ... Я пытаюсь смоделировать объект Image, и, пройдя этапы TDD, я начал с простого объекта, который в конечном итоге превратился в ...

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

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

Конечно, обязательные тесты ...

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

Пока все хорошо. Далее я хочу как-то представить физический файл в классе. Это может быть путь к файлу

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

или серия байтов

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

(Пожалуйста, это не аргумент о БД и Файловой системе для хранения.)

На данный момент я не чувствую себя комфортно, потому что мое сознание дрейфует и начинает думать об инфраструктуре / деталях реализации. Где мой недостаток ?? Должен ли я заранее принять решение о деталях реализации? Нужен ли мне умный шаблон дизайна, чтобы справиться с этим? Помогут ли насмешливые рамки? Это проблема анализа объектов / проектирования, и я должен использовать инструменты UML? (Подожди, я подумал, что TDD был о дизайне?)

В любом случае, как мне преодолеть эту проблему? Я хочу сосредоточиться на проектировании своих объектов и не думать об инфраструктурных проблемах в это время?

Answer 1

Я думаю, вы могли бы начать не в том месте.Вы говорите: «Далее, я хочу как-то представить физический файл в классе» - почему?Какой тест не пройден, что привело к необходимости представлять физический файл?

Одна проблема заключается в том, что вы представляете представление через публичное свойство - действительно ли это то, что вы хотите сделать?Или же физическое представление может быть закрытым, доступ к нему возможен только через некоторые операции, которые вы решили реализовать (например, «LoadImage ()», «GetImageBytes ()»)?Если он остается закрытым, для ваших тестов не должно иметь значения, что такое реализация.

Answer 2

Вы слишком много внимания уделяете моделированию этого класса, а не реализации реального сценария.

imho, это большая разница в том, как решать проблемы, когда вы используете TDD.

Это то, что удерживает вас от добавления ненужных элементов в классы, и заставляет вас переходить к более простым проектам с меньшими затратами времени на предварительный анализ.

Сосредоточьтесь на сценариях, которые вам нужно реализовать. Позвольте этому стимулировать ваши потребности в этих классах и то, что вам нужно там.

Answer 3

В TDD разрабатываемый класс следует рассматривать с точки зрения извне.Откуда берется изображение?Что вы собираетесь делать с изображением?показать это?отправить его по сети?применить какое-то преобразование к нему?вставить в галерею?Ответы дадут направление для подражания.И следующий тест написать.Тесты должны определять дизайн, а не то, каким может быть класс Image.

Действительно, для приложения для рисования, генератора галереи или программы чтения электронной почты ImageObject будет другим, так как у класса, который будет использовать этот класс, разные потребности.