TDD - разработка через тестирование

[jangle]

Попробовал такой подход, очень понравилось. Вкратце сначала пишется тест, а затем уже код, который реализует этот тест. Движемся маленькими шажками. Единица итерации - класс, как можно меньше размером и проще. Сложный класс дробится на более простые. Тесты тоже получаются простыми.
Разработка похоже на складывание дома из кирпичиков. Только каждый кирпичик тщательно проверен и обладает стандартным интерфейсом. Т.е. идем от частного к более общему, снизу вверх. Большой плюс такого подхода, что после тебя остается не тонны говнокода, а структурированная объектная модель с готовым тестовым покрытием. А если надо что-то выкинуть и заменить, нет проблем, меняем один кирпич на другой и все! Я теперь все новые проекты буду делать через TDD

[Хакер]

viewtopic.php?f=45&t=43021

[jangle]

По ссылке обсуждение совсем другого вопроса

[iGrok]

По ссылке обсуждение совсем другого вопроса

А если внимательно прочитать топик?

[ger_kar]

Попробовал такой подход, очень понравилось. Вкратце сначала пишется тест

Каким образом пишется? В произвольной форме в виде простого текста, или составляются некие диаграммы или таблицы?

Единица итерации - класс, как можно меньше размером и проще. Сложный класс дробится на более простые.

В моем понимании класс - это некоторая конкретная сущность и как ее дробить по каким критериям? Может приведешь примеры?

Т.е. идем от частного к более общему, снизу вверх.

Ну это напоминает строительство от фонаря, т.е. начал строить, а что получиться неизвестно. Как то все очень странно. Если общую идею разбить на составляющие и проработать каждую часть тогда еще как-то понятно. А вот наоборот
Кстати есть такая штука как Rational Rose. Интересно применяет или применял ее кто-либо их форумчан на практике? Или это фигня на которую и не стоит заморачиваться?

[jangle]

Каким образом пишется? В произвольной форме в виде простого текста, или составляются некие диаграммы или таблицы?

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

В моем понимании класс - это некоторая конкретная сущность и как ее дробить по каким критериям? Может приведешь примеры?

Надо чтобы класс внутри был простым и понятным. Плохо когда в класс инкапсулируют туеву кучу говнокода, иногда чужого, непонятно как работающего. Такой класс надо переработать в несколько более простых, иначе когда все это, например, станет валится под новой версией ОС, там никто не разберется.

Ну это напоминает строительство от фонаря, т.е. начал строить, а что получиться неизвестно. Как то все очень странно. Если общую идею разбить на составляющие и проработать каждую часть тогда еще как-то понятно. А вот наоборот

Задачу разбивать надо в любом случае

[ger_kar]

Ну вообще для разбивания большой задачи на кусочки Rational Rose вполне себе удобное средство. Но разбить правильно, а не просто все раздробить, все равно задача нетривиальная (для меня по крайней мере).

[VmestoMobilnika]

Попробовал такой подход, очень понравилось. Вкратце сначала пишется тест, а затем уже код, который реализует этот тест. Движемся маленькими шажками. Единица итерации - класс, как можно меньше размером и проще. Сложный класс дробится на более простые. Тесты тоже получаются простыми.
Разработка похоже на складывание дома из кирпичиков. Только каждый кирпичик тщательно проверен и обладает стандартным интерфейсом. Т.е. идем от частного к более общему, снизу вверх. Большой плюс такого подхода, что после тебя остается не тонны говнокода, а структурированная объектная модель с готовым тестовым покрытием. А если надо что-то выкинуть и заменить, нет проблем, меняем один кирпич на другой и все! Я теперь все новые проекты буду делать через TDD

Все смешалось в доме Облонских. TDD не имеет прямого отношения ни к классам, ни к методу "снизу вверх", ни тем более не избавляет от говнокода. Снизу-вверх - это плохо даже с TDD. Сверху-вниз - почти всегда лучше, а уж вместе с TDD вообще прекрасно. Эти две технологии не только не конфликтуют, но прекрасно друг в друга интегрируются.

У меня есть сильное подозрение, что Вы не различаете понятия разработки через тестирование и юнит-тестирования.

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

Это тем более не TDD. И даже не юнит-тестирование. Это просто спецификация. Если она проверяется автоматически, то получается контрактное программирование. Но я сомневаюсь, что Вы подразумевали его, судя по "ТЗ в виде текста".