C # - стратегия для TDD при прототипировании

Question

Я считаю, что некоторые формы написания кода лучше подходят для TDD, чем другие.Особенно, красно-зеленые испытания рефактора.

В рефакторе «Красный / Зеленый» я начинаю со всех своих модульных тестов и провалю (красный).Затем я реализую свой код, пока все тесты не пройдут (зеленый).

Например, если у меня есть интерфейс, который должен быть реализован в 10-20 раз, я просто реализую интерфейс в классе, который устанавливает все методы для выброса NotImplementedException.Затем создайте тест для каждого открытого метода.Оттуда я просто пишу код для исправления тестов.

Процессы не всегда так просты.Например, я пишу базовый парсер Excel.Я не знаком с Excel Interop API.Мне проще просто написать код.Затем, методом проб и ошибок, я обнаружил дизайн своего класса.

В этом случае я пишу ненужное программное обеспечение.Прототипирование это просто, чтобы я мог понять, каким должен быть мой дизайн.(Может быть, мне нужно передать имя файла здесь, может быть, этот конструктор ...).

В конечном счете, я хотел бы сохранить TDD.Я верю, что он сохраняет мой код минимальным и худым .

Работает ли TDD для создания прототипов?Другими словами, есть ли подход, которым я могу следовать, чтобы позволить TDD работать на меня, даже когда я не совсем уверен, куда движется мой дизайн?

Answer 1

Да, но делайте это как API. Вместо того, чтобы гадать, как сделать что-то с Excel, решите, что вы хотите сделать в качестве конечного результата. (Пример: чтение ячеек от A0 до A100)

Затем, когда вы поймете, как он будет работать за этим интерфейсом, вы в конечном итоге увидите, что именно вы можете отключить и протестировать самостоятельно, и, возможно, что может работать лучше для дизайна. (Пример: напишите код для чтения от 0,0 до 0,100 и удалите буквенный код, поскольку он является более сложным без какого-либо усиления)

Не бойтесь аннулировать тесты из-за изменений в дизайне / поведении, они должны помочь, а не быть конкретными. (Пример: этот исходный тест для чтения ячеек от A0 до A100 следует удалить)

Answer 2

ИМХО, у вас было бы несколько вариантов:

• , чтобы отделить проблемы и абстрагировать сложное поведение от интерфейса.Затем вы можете использовать интерфейс для создания объекта Mock (http://code.google.com/p/moq/)
• . Используйте Pex & Moles, чтобы создать Mole для вашего Excel API (опять же, это фокусируется на разделении проблем вашего кода ..) и использовать вместо этого кротреального API в вашем модульном тесте

уверен, что у людей гораздо больше предложений, но это два моих любимых подхода