Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, DorfDepp, Вы писали:
DD>>...если они на практике ничего не ловят. Каждый метод будет прекрасно работать в изоляции, а упадет обязательно на нестыковке компонент, из-за старого формата данных в базе и т.п. Ради чего надо писать 10 минут метод и потом час-два к нему тесты, если пользы ровно ноль?
ГВ>А зачем вы пишете такие тесты, от которых пользы ровно ноль?
Я вообще никакие не пишу. Зачем фигней страдать? И так работы полно без этого интеллектуального онанизма.
Здравствуйте, DorfDepp, Вы писали:
DD>>>...если они на практике ничего не ловят. Каждый метод будет прекрасно работать в изоляции, а упадет обязательно на нестыковке компонент, из-за старого формата данных в базе и т.п. Ради чего надо писать 10 минут метод и потом час-два к нему тесты, если пользы ровно ноль?
ГВ>>А зачем вы пишете такие тесты, от которых пользы ровно ноль?
DD>Я вообще никакие не пишу. Зачем фигней страдать? И так работы полно без этого интеллектуального онанизма.
Может, потому, что ты их и не пишешь, у тебя работы полно? "Чего там думать, трясти надо!" (tm)
Здравствуйте, VladD2, Вы писали:
VD>Зачем писать синтетический тест тестирующий отдельную функцию когда можно написать программу компиляция и запуск которой проверит эту функцию в сто раз лучше?
[...]
В твоём сообщении я со всем согласен, кроме собственно примера с компилятором. Для тебя понятие "компилятор" имеет сильно другой смысл, чем ожидался мне и многим другим.
Для тебя образец понятия компилятора — это компилятор Nemerle, у которого на входе названный язык, а на выходе псевдокод машины .NET. У тебя корректность результата — фактически единственный чёткий фактор, а логика работы проста и понятна.
Когда же я представляю себе что-то под словом "компилятор", мне скорее всего вспоминается gcc. Ты ещё как-то можешь проверить корректность компиляции сравнением вывода программы с ожидаемым; более того, существенная часть тестов это и делает. Но, например, проверять так оптимизации просто нереально — они не дают тебе однозначно проверяемого вывода. Результат работы оптимизатора неустойчив (очень похожие версии после лёгких корректировок коэффициентов могут дать совершенно разный выходной код), вариантов входных данных безумное количество. Тут сравнивать вывод с ожидаемым методически некорректно — на простых примерах проблемы не проявляются, а сложные имеют слишком много степеней свободы. Устойчивый смысл возникает только у статистики на большом количестве примеров. В такой системе можно тестировать только отдельные мелкие подсистемы, а в этом случае тесты или являются юнит-тестами, или очень похожи на них.
Здравствуйте, DorfDepp, Вы писали:
ГВ>>А зачем вы пишете такие тесты, от которых пользы ровно ноль? DD>Я вообще никакие не пишу. Зачем фигней страдать? И так работы полно без этого интеллектуального онанизма.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, netch80, Вы писали:
N>В твоём сообщении я со всем согласен, кроме собственно примера с компилятором. Для тебя понятие "компилятор" имеет сильно другой смысл, чем ожидался мне и многим другим.
Так может проблема в твоем не верном восприятии этого понятия?
N>Для тебя образец понятия компилятора — это компилятор Nemerle, у которого на входе названный язык, а на выходе псевдокод машины .NET. У тебя корректность результата — фактически единственный чёткий фактор, а логика работы проста и понятна.
Ну, да. Я работаю непосредственно с Nemerle. Но все что ты сказал справедливо для любого компилятора (точнее даже, транслятора). Ну, разве что за исключением "логика работы проста и понятна". Как раз логика работы сложна и не поддается восприятием одним человеком в принципе (хотя ее всего пару метров).
N>Когда же я представляю себе что-то под словом "компилятор", мне скорее всего вспоминается gcc. Ты ещё как-то можешь проверить корректность компиляции сравнением вывода программы с ожидаемым; более того, существенная часть тестов это и делает. Но, например, проверять так оптимизации просто нереально — они не дают тебе однозначно проверяемого вывода.
Ну, почему же? В проле реально. Делая оптимизацию нужно проверять две вещи:
1. Компилятор выдает код семантически эквивалентный оному генерированному без оптимизации.
2. Оптимизация ускоряет некоторые юзкейсы.
Это тестами делается на раз.
Возможно, еще, проверить, что оптимизация генерирует некоторые инструкции. Тут систему тестирования нужно расширить, чтобы она декомпилировала исходник с и искала в нем некоторый паттерн.
Плюс оптимизатор — это на самом деле отдельный модуль. Его можно тестировать отдельно с помощью специальной утилиты.
N>Результат работы оптимизатора неустойчив (очень похожие версии после лёгких корректировок коэффициентов могут дать совершенно разный выходной код),
Та же фигня с любым компилятором. От того, например, в нашей тестовой утилите можно задавать опции компилятора в виде специального комментария-DSL-я. Например, вот как включается оптимизация.
N> вариантов входных данных безумное количество.
Входных данных для любого компилятора можно неограниченно нагенерировать.
Но для сочетания исходник + опции результат должен быть один и тот же. Компилятор не может быть генератором случайных чисел. Это всегда чистая функция.
N> Тут сравнивать вывод с ожидаемым методически некорректно — на простых примерах проблемы не проявляются, а сложные имеют слишком много степеней свободы.
Выдумываешь. Всегда можно написать пример демонстрирующий проблему. Так баги в компиляторах и ловятся.
N> Устойчивый смысл возникает только у статистики на большом количестве примеров. В такой системе можно тестировать только отдельные мелкие подсистемы,
Использование статистики для отладки? Это ты здорово придумал. Еще генератор случайных чисел для этого здорово использовать!
N>а в этом случае тесты или являются юнит-тестами, или очень похожи на них.
Под определение юнит-тестов — это не проходит. Тестируются не отдельные методы, а случаи использования. Это специализированная тестовая система. По уму для любого софта надо придумывать что-то подобное.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, DorfDepp, Вы писали:
DD>>>...если они на практике ничего не ловят. Каждый метод будет прекрасно работать в изоляции, а упадет обязательно на нестыковке компонент, из-за старого формата данных в базе и т.п. Ради чего надо писать 10 минут метод и потом час-два к нему тесты, если пользы ровно ноль? ГВ>>А зачем вы пишете такие тесты, от которых пользы ровно ноль? DD>Я вообще никакие не пишу. Зачем фигней страдать? И так работы полно без этого интеллектуального онанизма.
Если ты действительно так считаешь, то ты круто ошибаешься. Собственно, не имеет значения, как называть "проверочные программы" — юнит-тестами, функциональными тестами, интеграционными, модульными, ещё как-то, суть не в названии (оно относится только к характеристикам охватываемой предметной области). Суть в том, что такими программами решаются задачи автоматизации контроля функционирования продукта. Я не спорю, от них можно подчас отказаться полностью, но именно что "подчас".
В твоём случае, похоже, кто-то увлёкся тестами отдельных кусочков, не занявшись плотно тестами композиций (сознательно не употребляю общепринятую терминологию). Такое может случиться по уйме различных причин: от неопытности до формализма и пренебрежения автоматическими проверками. И ты сейчас обобщаешь на весьма шатком основании, что, мол, юнит-тесты вообще нафиг не нужны. Если за какой-нибудь самопальной бухгалтерией придётся всё пересчитывать на счётах, это же не означает, что программисты вообще не нужны, правильно? Ну так и не опускайся до такого же уровня.
Собственно, в твоём вопросе заключена часть ответа: если программа не решает той задачи, для которой она, вроде бы, предназначена — нужно изменить программу. То есть если вы ждёте, что тесты обеспечат проверку работоспособности комбинации модулей, то нужно просто написать соответствующие тесты. Ну а если их нет, то ясное дело — проверяться комбинирование не будет. А как назвать эти тесты — юнит-, хрюнит-, грюнит-... Да хоть груздём назови, лишь бы вы у себя понимали, что как названо. Не нужно зацикливаться на глубоком смысле названий: если некоторый тест можно написать в рамках соглашений какой-то тестовой инфраструктуры (CppUnit, JUnit, NUnit, легионы их), но он по каким-то критериям не подходит под определение юнит-тест — это проблема самого определения, но никак не того, кто пишет тесты. И уж точно это не причина отказываться от самого тестирования, если имеется необходимость оного.
А безголовый подход (читай, без ясного понимания "зачем" — т.е. без ясной постановки задачи в контексте ясных требований) — вредит всегда и всем. Это справедливо не только для программирования.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
N>> Устойчивый смысл возникает только у статистики на большом количестве примеров. В такой системе можно тестировать только отдельные мелкие подсистемы, VD>Использование статистики для отладки? Это ты здорово придумал. Еще генератор случайных чисел для этого здорово использовать! :)
А что тебя в этом удивляет? Совершенно нормальный метод — случайность в выборе конкретных значений входных данных при условии 1) знания, что должно получиться в результате, с необходимой точностью и 2) в случае ошибки теста, тестовая среда сохраняет конкретные входные данные, чтобы дать человеку на проверку. Желательно также чтобы 3) тестовая среда могла, найдя так случайным образом пример нарушения теста, редуцировать его до предельно простого (не для всех видов тестов, только для поведенческих или других, где в принципе можно говорить о последовательном упрощении задачи, но, например, PropEr это умеет).
Да, это может быть непривычно в том смысле, что вроде бы в уже проверенном находится новая проблема, ну так всё равно ты их находишь раньше пользователя.
Конкретное применение случайных данных будет зависеть от задачи. Для компилятора это может быть, например, выход кодогенератора, у которого примерно известен результат, но в зависимости от ответов ГСЧ создаётся разное количество функций, перераспределяется код между ними, рисуются циклы и связи выполнения, и так далее.
И статистика — тоже важный показатель, если известно, что какое-то воздействие должно статистически улучшать результат.
N>> Тут сравнивать вывод с ожидаемым методически некорректно — на простых примерах проблемы не проявляются, а сложные имеют слишком много степеней свободы. VD>Выдумываешь. Всегда можно написать пример демонстрирующий проблему. Так баги в компиляторах и ловятся.
Постфактум — да, можно. Можно также запланированно тратить некоторую часть времени на придумывание "а какие тут ещё могут быть подводные камни и как их найти". Но в большинстве случаев примеры будут уже из практически достигнутого (или у пользователя, или у тестировщиков).
N>>Когда же я представляю себе что-то под словом "компилятор", мне скорее всего вспоминается gcc. Ты ещё как-то можешь проверить корректность компиляции сравнением вывода программы с ожидаемым; более того, существенная часть тестов это и делает. Но, например, проверять так оптимизации просто нереально — они не дают тебе однозначно проверяемого вывода. VD>Ну, почему же? В проле реально.
Где, простите?
VD> Делая оптимизацию нужно проверять две вещи: VD>1. Компилятор выдает код семантически эквивалентный оному генерированному без оптимизации. VD>2. Оптимизация ускоряет некоторые юзкейсы. VD>Это тестами делается на раз.
Ты так выловишь только очень простые юзкейсы. Конечно, легко проверить, что код вида int f(int x) { int a = x; return a; } будет без оптимизации сделан в виде снятия значения со стека, укладки его туда снова и затем снятия в регистр, а в случае оптимизации вместо трёх операций будет одна. Но это вообще неинтересный случай. Интересный пойдёт, когда функции на входе в оптимизатор имеют размеры в тысячи команд (стандартная ситуация в случае inline функций, раскрытия шаблонов и макросов). Тут ты тестами типа "подать товарный поезд на вход и получить простыню, идентичную данной, на выходе" долетишь в лучшем случае до следующей минорной версии, в которой всё это превратится в тыкву, потому что из-за смены пары констант подсчёт оптимума пойдёт по другому пути, регистры сдвинутся и в выводе не окажется ни одной совпадающей команды.
N>>а в этом случае тесты или являются юнит-тестами, или очень похожи на них. VD>Под определение юнит-тестов — это не проходит. Тестируются не отдельные методы, а случаи использования.
Повторюсь, я не считаю границу между юнит-тестами и тестами более высокого порядка, которые проверяют поведение, насколько принципиальной; в принципе это всё тесты функционирования какой-то части полной системы, и от размера и сложности этой части зависит только объём тестов и работа по настройке среды тестирования.
VD> Это специализированная тестовая система. По уму для любого софта надо придумывать что-то подобное.
Здесь категорически согласен, в том случае, если эта тестовая система окупится в разработке.
Здравствуйте, Aikin, Вы писали:
AVK>>Не так — когда сам дизайн меняется. Юнит-тесты при этом большими кусками перестают выполнять свою работу. Всего лишь. Это, в свою очередь, удорожает рефакторинг. A>Вывод не верный. Хоть и похоже на правду. Давай я свою "правду" озвучу: A>Когда сам дизайн менятся, функциональность существующих классов переноситься в другие классы.
Заблуждение, притом сильное. Функциональность существующих классов запросто может быть убрана полностью или трансформирована так, что старые юнит-тесты будет проще выкинуть, чем отрефакторить.
A>Чем большее количество логики меняет свое местоположение тем проще ошибиться и сложнее убедиться в том, что мы ничего не сломали рефакторингом. Чтобы убедиться в правильности рефакторинга нужно делать его ооочень внимательно и осторожно. А после окончания нужно обязательно прогнать систему по основным сценариям. Выявятся баги (куда же без них). Чтобы локализовать баг и исправить причину приходится дебажить, иногда очень долго. Это, в свою очередь, удорожает рефакторинг.
Так "дорогие" рефакторинги-то как раз и интересны. С другой стороны, на них летит к чёртовой бабушке вся стройная картина test-first, unit-test everywhere и всякие похожие лозунги.
AVK>>>>Об обычных. Глубокий рефакторинг ломает конктракты — ломаются все связанные с этим тесты. A>>>Любой рефакторинг идет итеративно, небольшими шажками. AVK>>Не любой. A>Тогда удачи тебе в глубоких рефакторингах одним махом.
Не понимаю твоего сарказма: такое делают нередко и к тому же — удачно.
A>>>При "очень глубоком рефакторинге" классы вместе с тестами проще выкинуть, чем изменять. AVK>>Классы — нет, не проще. Тесты — да, проще. О чем и речь. A>Юнит-тесты всегда значительно проще чем логика класса. Иначе в них практического смысла нет. A>Если же тест сложнее класса, то (на это должна быть причина) класс этот отвечает за критическую функциональность.
Как-то многовато у тебя выводится за рамки рассмотрения: глубокий рефакторинг, критическая функциональность, большие изменения дизайна. Такое ощущение, что твои высказывания на самом деле касаются программ, работающих, в основном, с чужим сложным кодом, функциональность которых не слишком "критична", а шаг вправо, шаг влево — и там уже "Дорого!" или "Критично!" Тогда как на практике нужно писать и критически важный код, и глубоко рефакторить, ну и много чего ещё.
Хм. Или это у меня одного такое впечатление?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Aikin, Вы писали:
AVK>>>>Когда сильно ковыряешь, unit-тесты очень плохи, так как висят свинцовой гирей и мешают проводить глубокий рефакторинг. А толку от них никакого, так как они пачками становятся просто неактуальными на новом дизайне. N>>>И что с того? AVK>>Дополнительная работа. A>А дебагинг очень нетривиального бага внесенного рефакторингом без тестов это не доп. работа? А работа QA который нашел этот баг? А время и головную заказчика, который не смог сделать то что ему нужно или еще хуже сделал то, что ему не нужно ты учитываешь?
Ну не выдумывай страшилок. Глубокая переработка подчиняется всем тем же правилам, что и любая другая разработка — вероятность сделать нетривиальную ошибку, в общем-то, одинакова в обоих случаях и зависит не от "глубины рефакторинга", а, скорее, от самого разработчика. Короче говоря, тут уже совсем другие факторы начинают играть.
Pzz>>>>>А иначе придется еще и тесты ковырять, не только класс. AVK>>>>Вот именно. N>>>И ничего в этом плохого нет. Если тест сломался, значит, его зацепило.
AVK>>Вопрос лишь в адекватности этого зацепления. В большинстве случаев, при сильном рефакторинге, я и так в курсе, какие тесты и почему сломаются до их запуска. Т.е. их срабатывание не приносит никакой пользы, и никто их не чинит, их либо основательно переписывать надо сразу, до запуска, либо вообще выкидывать, если тестируемый ими контракт изменился до неузнаваемости. A>Ценность тестов при рефакторинге не только в том, чтобы указать что именно ты сломал, но и в том, чтобы в конце ты все "вернул на место". Т.е. оставил логику в том же состоянии что и до рефакторинга. Это раз.
Это прямо конфликтует с необходимостью выбросить часть тестов после рефакторинга. То есть получается так, что в некоторых (и достаточно частых) случаях такая теория не применима.
A>Второй момент заключается в том, что хоть ты и предполагаешь какие именно тесты упадут (не будем говорить про изменение контрактов, когда компилятор может указать на ошибки), не не можешь быть 100% уверен, что не упадет что-то еще или что некоторые тесты изменения не затронут.
Так если контракт поменялся, то юнит-тесты не соответствующие новому контракту могут показывать что угодно — это только говорит о необходимости их переписать.
A>Опять же мы не рассматриваем очевидные случаи. Для них тестов (юнит) не будет.
Ну вот, снова ты отрезаешь кусок от проблемной области. Ты бы уж сразу её обрисовал, что ли. А то, куда ни кинь — по твоим словам выходит либо тривиальный случай, либо какое-то критическое ограничение, которое "не трогай", либо вообще не пойми, что.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Собственно, в твоём вопросе заключена часть ответа: если программа не решает той задачи, для которой она, вроде бы, предназначена — нужно изменить программу. То есть если вы ждёте, что тесты обеспечат проверку работоспособности комбинации модулей, то нужно просто написать соответствующие тесты. Ну а если их нет, то ясное дело — проверяться комбинирование не будет.
Проблема в том, что на большинстве реальных задач написание таких тестов занимает по времени больше, чем само решение задач. При этом при рефакторинге эти тесты все равно отваливаются, из-за изменений как архитектуры, так и требований. Именно по этой причине написание тестов в большинстве случаев это впустую потраченное время.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Если ты действительно так считаешь, то ты круто ошибаешься. Собственно, не имеет значения, как называть "проверочные программы" — юнит-тестами, функциональными тестами, интеграционными, модульными, ещё как-то, суть не в названии (оно относится только к характеристикам охватываемой предметной области). Суть в том, что такими программами решаются задачи автоматизации контроля функционирования продукта. Я не спорю, от них можно подчас отказаться полностью, но именно что "подчас".
ГВ>В твоём случае, похоже, кто-то увлёкся тестами отдельных кусочков, не занявшись плотно тестами композиций (сознательно не употребляю общепринятую терминологию). Такое может случиться по уйме различных причин: от неопытности до формализма и пренебрежения автоматическими проверками. И ты сейчас обобщаешь на весьма шатком основании, что, мол, юнит-тесты вообще нафиг не нужны. Если за какой-нибудь самопальной бухгалтерией придётся всё пересчитывать на счётах, это же не означает, что программисты вообще не нужны, правильно? Ну так и не опускайся до такого же уровня.
ГВ>Собственно, в твоём вопросе заключена часть ответа: если программа не решает той задачи, для которой она, вроде бы, предназначена — нужно изменить программу. То есть если вы ждёте, что тесты обеспечат проверку работоспособности комбинации модулей, то нужно просто написать соответствующие тесты. Ну а если их нет, то ясное дело — проверяться комбинирование не будет. А как назвать эти тесты — юнит-, хрюнит-, грюнит-... Да хоть груздём назови, лишь бы вы у себя понимали, что как названо. Не нужно зацикливаться на глубоком смысле названий: если некоторый тест можно написать в рамках соглашений какой-то тестовой инфраструктуры (CppUnit, JUnit, NUnit, легионы их), но он по каким-то критериям не подходит под определение юнит-тест — это проблема самого определения, но никак не того, кто пишет тесты. И уж точно это не причина отказываться от самого тестирования, если имеется необходимость оного.
ГВ>А безголовый подход (читай, без ясного понимания "зачем" — т.е. без ясной постановки задачи в контексте ясных требований) — вредит всегда и всем. Это справедливо не только для программирования.
Отличный ответ. Вот в таком виде я вопрос вполне поддержу.
Здравствуйте, netch80, Вы писали:
DD>>Я вообще никакие не пишу. Зачем фигней страдать? И так работы полно без этого интеллектуального онанизма.
N>Может, потому, что ты их и не пишешь, у тебя работы полно? "Чего там думать, трясти надо!" (tm)
Работы у меня полно, но работаю я очень аккуратно, поэтому неожиданно ничего не падает. Может, раз в год от силы, или того реже.
Здравствуйте, DorfDepp, Вы писали:
ГВ>>А безголовый подход (читай, без ясного понимания "зачем" — т.е. без ясной постановки задачи в контексте ясных требований) — вредит всегда и всем. Это справедливо не только для программирования.
DD>Отличный ответ. Вот в таком виде я вопрос вполне поддержу.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Undying, Вы писали:
ГВ>>Собственно, в твоём вопросе заключена часть ответа: если программа не решает той задачи, для которой она, вроде бы, предназначена — нужно изменить программу. То есть если вы ждёте, что тесты обеспечат проверку работоспособности комбинации модулей, то нужно просто написать соответствующие тесты. Ну а если их нет, то ясное дело — проверяться комбинирование не будет.
U>Проблема в том, что на большинстве реальных задач написание таких тестов занимает по времени больше, чем само решение задач. При этом при рефакторинге эти тесты все равно отваливаются, из-за изменений как архитектуры, так и требований. Именно по этой причине написание тестов в большинстве случаев это впустую потраченное время.
Я бы не стал обобщать, большинство случаев — оно у каждого своё. Скорее, здесь имеет значение общий подход к тестированию. Если мы пишем тесты под влиянием какого-нибудь милого голубоглазого лозунга, вроде: "каждый метод непременно должен сопровождаться юнит-тестом" или "сначала непременно пиши тесты" — то да, есть приличный шанс нарваться на то, что большую часть времени мы будем тратить на переписывание тестов. Ну а если мы пишем тесты ради того, чтобы решить какие-то, вполне определённые задачи — то всё в порядке.
Например, мы хотим зафиксировать контракт и предостеречь сами себя от случайного его изменения. Отлично, пишем набор тестов. И после этого нет никакого смысла жаловаться, если вдруг мы всё же решили сильно поменять контракт — на момент принятия решения о покрытии тестами мы были на 101% уверены в его стабильности.
Или, скажем, хотим, чтобы вот этот набор функций был очень надёжным и протестирован в мыслимых и немыслимых условиях, и плевать, что когда-то он поменяется — снова пишем набор тестов. И снова, даже если этот набор функций раньше или позже оказался выкинут полностью — нет смысла жаловаться, поскольку тестами мы решали актуальную в какой-то момент задачу.
Ещё тесты можно писать банально ради отладки — тестовая инфраструктура зачастую вполне подходит для этого. тут вообще жаловаться не на что и незачем.
Суть в том, что мы сначала определяем задачу, имеющую практический смысл, ради решения которой пишется тест, и только потом, после того, как мы её сформулировали, мы пишем тесты. Если окажется, что мы сплоховали во время выделения задачи — тесты тут не при чём, это лечится совсем с другого конца.
Но повторюсь, если тесты пишут только потому, что так сказал Гуру Методологии — всё, пиши пропало. Будет срач, вопли, недоумённые восклицания и, что самое забавное — тесты плавно выйдут из эксплуатации одновременно с изменением глубины веры в заветы Великого. Короче, будет всё, как всегда в нашем зоопарке.
Premature testing is a root of evil, так сказать. Ключевое слово, как всегда — Premature.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, DorfDepp, Вы писали:
DD>...если они на практике ничего не ловят. Каждый метод будет прекрасно работать в изоляции, а упадет обязательно на нестыковке компонент, из-за старого формата данных в базе и т.п. Ради чего надо писать 10 минут метод и потом час-два к нему тесты, если пользы ровно ноль?
Присоединяюсь ко всем, кто высказался в пользу юнит-тестов.
Могу добавить только, что вот прямо вчера мне удалось спасти релиз от весьма неочевидного бага именно благодаря отвалившемуся юнит-тесту.
Пример прямо из жизни, свежее не бывает.
Здравствуйте, Геннадий Васильев, Вы писали:
A>>Опять же мы не рассматриваем очевидные случаи. Для них тестов (юнит) не будет.
ГВ>Ну вот, снова ты отрезаешь кусок от проблемной области. Ты бы уж сразу её обрисовал, что ли. А то, куда ни кинь — по твоим словам выходит либо тривиальный случай, либо какое-то критическое ограничение, которое "не трогай", либо вообще не пойми, что. Re: Нафига нужны юнит-тесты?
Здравствуйте, VladD2, Вы писали:
VD>Автоматизировать обезьянью работу.
Спасибо Кэп! Давай я разверну, а ты потом прокоментируешь.
Ну и чтобы было интересно, то вот часть моей "обезьяньей работы":
Приходит запрос от Бизнеса в виде: "большая кнопка должна делать Чпок". Ты понимаешь, что это может означать все что угодно. Выбираешь 2-3 наиболее вероятных варианта. Начинаешь слать письма. После переписки задача понятна. Начинаешь анализировать. Вылезли нюансы/проблемы/ограничения. Опять переписка. Видишь, что переписки мало -- звонишь. В параллель ты делаешь этот функционал. Показываешь, исправляешь. и т.д.
Как я ненавижу это, но это моя работа. Внимание вопрос: как это автоматизировать?
А еще есть обезьянья работа по переводу спецификаций и требований в код. Написание документации. И проч.
СУВ, Aikin
ЗЫ Обезьянья работа озвученая АндреемВК мне нравится -- люблю рефакторить. Жаль делаю это не так часто.
Здравствуйте, Aikin, Вы писали:
A>Ну и чтобы было интересно, то вот часть моей "обезьяньей работы": A>Приходит запрос от Бизнеса в виде: "большая кнопка должна делать Чпок". Ты понимаешь, что это может означать все что угодно. Выбираешь 2-3 наиболее вероятных варианта. Начинаешь слать письма. После переписки задача понятна. Начинаешь анализировать. Вылезли нюансы/проблемы/ограничения. Опять переписка. Видишь, что переписки мало -- звонишь. В параллель ты делаешь этот функционал. Показываешь, исправляешь. и т.д. A>Как я ненавижу это, но это моя работа. Внимание вопрос: как это автоматизировать?
Это не обезьянья работа. Это даже не работа для программиста. Тут хорошо бы найти подходящего специалиста которому бы эта работа нравилась, и который выполнял бы ее творчески. Вот от что-нибудь придумал бы.
A>А еще есть обезьянья работа по переводу спецификаций и требований в код. Написание документации. И проч.
А вот это как раз автоматизировать можно. Нужно формализовать спецификации. Придумать для них ДСЛ (возможно не один). Написать генераторы кода которые превратят спеки в рабочий код.
Структуру документации тоже таким образом можно создать. Саму документацию придется писать вручную (ИИ пока нет). Но это опять же не обязьянья работа. И опять работа не для программиста, а для тех.писателя.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
