Наконец-то я понял, зачем нужны тесты. Наверное, дзен пришел Я раньше никогда их не писал, зачем? Все на глаз.
А сейчас — накалял что-нибудь, написал тест, проходит — хорошо. Накалякал еще что-нибудь, запустил тесты — проходит — хорошо, не проходит — что-то не так, надо исправлять, не надо лезть в браузер или запускать прогу. Лепота!
Здравствуйте, Grienders, Вы писали:
G>Наконец-то я понял, зачем нужны тесты. Наверное, дзен пришел Я раньше никогда их не писал, зачем? Все на глаз. G>А сейчас — накалял что-нибудь, написал тест, проходит — хорошо. Накалякал еще что-нибудь, запустил тесты — проходит — хорошо, не проходит — что-то не так, надо исправлять, не надо лезть в браузер или запускать прогу. Лепота!
Наверное ты научился писать тесты. Просто когда тестов нужно написать в десять раз больше, чем текста программы, то это ломает.
Здравствуйте, Grienders, Вы писали:
G>Наконец-то я понял, зачем нужны тесты. Наверное, дзен пришел Я раньше никогда их не писал, зачем? Все на глаз. G>А сейчас — накалял что-нибудь, написал тест, проходит — хорошо. Накалякал еще что-нибудь, запустил тесты — проходит — хорошо, не проходит — что-то не так, надо исправлять, не надо лезть в браузер или запускать прогу. Лепота!
Ну дык, час работы компьютера — меньше рубля, час работы тестировщика — от 500 рублей. Компьютер можно заставить работать когда хочется тебе, у тестировщика, обычно, расписание. Компьютер не сфилонит, и глаз у него не замылится — одну и ту же проверку делать в стопятисотый раз. Понятно, что автоматизированные тесты это хорошо. Главное до абсурда — до юнит-тестов — не доводить.
M>А следующий — перестать это делать и написать статью вроде этой
Если ваша цель — написать статью, то на здоровье. А если речь идет о сокращении сроков разработки и удобства развития\сопровождения ПО, то без TDD никак.
Есть области, где никакой другой подход кроме TDD (или что-то по его мотивам) не работает. Например, разработка всяческих алгоритмов обработки данных.
Там процесс примерно такой:
1. собрать набор данных для разработки и набор для тестирования;
2. если надо, то каким-нибудь образом сделать ground truth для набора — эталонный результат, который должен выдать разрабатываемый алгоритм;
3. написание тестов для проверки произвольной реализации алгоритма (как качества, так и скорости);
4. поиск существующих решений проблемы;
5. прогон существующих реализаций на данных из (1);
6. выводы;
7. разработка своего решения, как непрерывный итеративный процесс: реализация фичи или подхода — тестирование; реализация — тестирование; ...; оптимизация — тестирование; ...; конец.
Если не придерживаться данного процесса, то конфетка вряд ли получится.
Здравствуйте, abibok, Вы писали:
A>Если ваша цель — написать статью, то на здоровье. А если речь идет о сокращении сроков разработки и удобства развития\сопровождения ПО, то без TDD никак.
Ну это ваша субъективная точка зрения.
При этом вам не кажется странным что при этом большинство компаний и инженеров не используют TDD и при этом разрабатывают ПО в достаточно сжатые сроки?
Здравствуйте, Nuzhny, Вы писали:
N>Есть области, где никакой другой подход кроме TDD (или что-то по его мотивам) не работает. Например, разработка всяческих алгоритмов обработки данных.
То что вы описали это не TDD, а "что-то по его мотивам" для data scientists'ов (но не инженеров)
Здравствуйте, mapnik, Вы писали:
N>>Есть области, где никакой другой подход кроме TDD (или что-то по его мотивам) не работает. Например, разработка всяческих алгоритмов обработки данных. M>То что вы описали это не TDD, а "что-то по его мотивам" для data scientists'ов (но не инженеров)
И инженеров тоже. Например, можно поставить задачу рефакторинга, оптимизации, переноса кода на другую платформу. То же популярное переписывание кода на GPU. Видишь ли, алгоритмы придумывают по большей части учёные, а реализуют их и адаптируют под конкретные задачи уже инженеры.
Здравствуйте, Nuzhny, Вы писали:
N>Если не придерживаться данного процесса, то конфетка вряд ли получится.
Если придерживаться данного процесса, то конфетка не получится точно, с гарантией. У вас в описании процесса упущена такая маааленькая деталь как написание кода. Очень много описания всего самоочевидного(особенно радуют пункты типа "поиск существующих решений проблемы" ) для тестирования но... ни слова о том, что этот алгоритм нужно придумать и закодировать.
И в этом ИМХО основная проблема ТDD.
Кстати если пунктом 0 добавить "разработка и реализация алгоритма", то ничего не пострадает. Хотя это уже не будет православным TDD конечено.
Здравствуйте, Nuzhny, Вы писали:
N>Есть области, где никакой другой подход кроме TDD (или что-то по его мотивам) не работает. Например, разработка всяческих алгоритмов обработки данных. N>Там процесс примерно такой:
[] N>7. разработка своего решения, как непрерывный итеративный процесс: реализация фичи или подхода — тестирование; реализация — тестирование; ...; оптимизация — тестирование; ...; конец.
N>Если не придерживаться данного процесса, то конфетка вряд ли получится.
Речь идет о тестовых примерах или о юнит-тестах?
В моей практике юнит-тесты ну никак не прижились.
Последний раз пытался их применить в построении адаптивной сетки (Adaptive cartesian mesh). Вроде бы та самая "разработка всяческих алгоритмов обработки данных"...
Написание 6 тестов заняло 2 дня и 1100 строк кода. При этом они покрыли, от силы, 1% от возможных вариантов.
Да, можно потратить кучу времени, написать тесты, убедиться, что всё работает как надо и ... больше эти тесты не понадобятся. Т.к. код, который они тестируют, пишется, грубо говоря, "один раз", изменения в него вносятся очень-очень редко. Получается, что время будет потрачено впустую.
Поэтому по-прежнему рулят танковые клинья и ковровое бомбометание тестовые примеры и run-time проверки (банальные assert'ы).
Возможно там, где методы примитивные и меняются по дцать раз на дню, юнит-тесты будут более уместны.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Nuzhny, Вы писали:
N>И инженеров тоже. Например, можно поставить задачу рефакторинга, оптимизации, переноса кода на другую платформу. То же популярное переписывание кода на GPU. Видишь ли, алгоритмы придумывают по большей части учёные, а реализуют их и адаптируют под конкретные задачи уже инженеры.
1) Как я вам уже написал — это не TDD
2) Все шаги которые вы привели — это путь неопытных или слабых разработчиков. Хорошему инженеру достаточно 3 шагов
а) реализовать алгоритм в голове или на бумаге, б) реализовать в коде, с) протестировать
Все
Здравствуйте, Yoriсk, Вы писали:
Y>Если придерживаться данного процесса, то конфетка не получится точно, с гарантией. У вас в описании процесса упущена такая маааленькая деталь как написание кода. Очень много описания всего самоочевидного(особенно радуют пункты типа "поиск существующих решений проблемы" ) для тестирования но... ни слова о том, что этот алгоритм нужно придумать и закодировать.
Пункт 7! Как можно было его пропустить?
Далее за ним следует (при необходимости): интеграция, интеграционные тесты, тестирование тестерами, написание документации...
Y>И в этом ИМХО основная проблема ТDD. Y>Кстати если пунктом 0 добавить "разработка и реализация алгоритма", то ничего не пострадает. Хотя это уже не будет православным TDD конечено.
Разработка начинается после. Смотри, тебе дали довольно академическую задачу, скажем, написания модуля по сортировке большого массива данных, который не помещается в ОЗУ. Или может как помещаться, так и не помещаться. Допустим, чаще всего объём до 1 Гб — в 50% случаев, в 40% уже до 4 Гб, в 10% — до 10 Гб. И при этом процессорное время — дефицит. Но можно заюзать GPU, если доступно конечно.
1. Так вот, сначала надо точно очертить границы проблемы и все возможные случаи. То есть сделать наборы данных, которые будут встречаться, с разным их распределением, как по размерам, так и по характеру.
2. Как проверять результат? Можно сгенерировать эталонные данные, положить их на отдельную машину, которая будет просто принимать результат от очередного алгоритма и сравнивать. Или проверять любым другим способом на лету. Вариантов много, но они должны быть учтены и реализованы ещё ДО начала разработки.
3. Далее мы пишем тесты для данных.
4. Берём реализации всех подходящих алгоритмов — их вагон.
5. Тестируем.
6. Смотрим результаты, выбираем подходящее(ие) решение(я).
7. Начинаем программировать — тестировать, программировать — тестировать, оптимизировать — тестировать.
В итоге у нас будет решение, которое объективно на собранных данных лучше остальных удовлетворяет требованиям.
Если же начинать кодирование сразу, то непонятно, что будет в результате. А оно и правда оптимально? Насколько результат стабилен? Почему выбран именно этот подход? Я не знаю, как по-другому организовать процесс.
Здравствуйте, mapnik, Вы писали:
M>1) Как я вам уже написал — это не TDD M>2) Все шаги которые вы привели — это путь неопытных или слабых разработчиков. Хорошему инженеру достаточно 3 шагов M>а) реализовать алгоритм в голове или на бумаге, б) реализовать в коде, с) протестировать M>Все
Хорошо, для слабых, так для слабых. Жаль, что сильные инженеры мне в жизни почти не встречались.
Я раньше никогда их не писал, зачем? Все на глаз. 
) для тестирования но... ни слова о том, что этот алгоритм нужно придумать и закодировать.
