Здравствуйте, matumba, Вы писали:
M>Здравствуйте, jazzer, Вы писали:
M>>>TDD применимо к маленьким, чётко оговоренным библиотечкам
J>>Открою тайну: нормальные сложные системы состоят из "маленьких, чётко оговоренных библиотечек".
M>Jazzer, у меня тоже есть для вас сюрприз! "маленькие, чётко оговоренные библиотечки" — это СТРОИТЕЛЬНЫЕ БЛОКИ, ничего не значащие сами по себе.
Золотые слова!
"Строительный блок" — это как раз по-английски и есть unit
И Unit Testing — это _только_ о тестировании этих самых блоков.
А то, что ты пытаешься притянуть практику тестирования блоков к тестированию системы в целом — это уже твои проблемы.
Потому что для тестирования системы в целом есть system tests, integration tests и т.д.
Если продолдать строительную тематику, то очевидно, что приемы и методики тестирования кирпичей и труб совершенно не применимы к тестированию построенного здания целиком.
Остальное скипнуто как не относящееся к юнит-тестированию.
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, Mystic, Вы писали:
M>>Так и получается. Только UNIT-тестирование сводится к разработке внешнего приложения, которое читает последовательно файлы из парки, парсит их на предмет данных и результатов, данные загоняет в алгоритм и проверяет результат...
K>Это неправильный подход. При правильном подходе тест кормит алгоритму (через моки/стабы) некий заранее сформированный инпут, и затем сравнивает результат с тем, который должен быть. Причём тесты пишутся идеально просто в случае, если используется IoC, ибо тогда ничего не стоит вместо компонента, "который читает последовательно файлы из папки" (С), подсунуть мок, который вернёт то, что надо — да хоть захардкоженный прямо в тесте инпут. Алгоритмы — это именно то, что в 99.(9)% случаев отлично поддаётся юнит-тестированию.
Во-первых, как заметили ниже, это уже не UNIT-тестирование. Во-вторых, я не вижу принципиальной разницы между моим и вашим способом. В третьих, этот метод хорош, когда есть результат, который должен быть. А если его нету?
M>>Jazzer, у меня тоже есть для вас сюрприз! "маленькие, чётко оговоренные библиотечки" — это СТРОИТЕЛЬНЫЕ БЛОКИ, ничего не значащие сами по себе. Будучи же собранные в систему, они и составляют ту сложную хренотень, которую не так просто протестировать! G>Неправда. Каждый кирпичик тестируется отдельно...
Такой примитивный уровень не интересен. Плюс из моего исходного сообщения пропущены ключевые слова, читайте внимательно.
M>>Более того, метафора "кирпичей" хороша только в статьях — на деле, взаимодействие и проникновение кода куда сложнее. G>Это зачастую признак хренового кода.
Если ваши задачи решают квадратные уравнения, это ещё не повод думать, будто всё на свете так легко поддаётся декомпозиции.
M>>Если модуль А делает работу, Б её обновляет, при этом модуль В синхронно работает с А и Б, обрабатывая результаты обоих, я бы не стал на вашем месте бросаться это тестировать "юнит-тестами" — рискуете поседеть и всё равно ни черта не решить. G>Такие случаи находятся за пределами компетенции юнит-тестов.
Как уже сказал, другие примитивные случаи не интересны. А судя по крикам студентов "Как, вы не пишете тесты?!?!" начинаешь опасаться за здоровье программирующих — уж не идолопоклонничеством ли они занимаются.
M>>Увлечение новым buzzword "TDD" — это ещё один манёвр известного "огонь и движение". G>TDD, это не тесты, TDD — методика дизайна кода, причем вполне хорошо работающая при детальном дизайне.
Спускаться к лингвистическим дебрям — это да, признак умного и квалифицированного оппонента.
TDD — buzzword, хорошо работающее на примитивных задачах. Сложные задачи продумать до деталей нереально, а когда твердолобые таки начинают писать спеки раньше программы, получается тот самый "исторически сложившийся маразм" в архитектуре. Итеративность — вот ключ разработки. А в такой динамике извините, тесты отдыхают.
Здравствуйте, jazzer, Вы писали:
J>И Unit Testing — это _только_ о тестировании этих самых блоков.
J>А то, что ты пытаешься притянуть практику тестирования блоков к тестированию системы в целом — это уже твои проблемы.
Капитан Очевидность, вам действительно интересен этот метод? Тогда могу только поздравить, все открытия у вас ещё впереди.
J>Потому что для тестирования системы в целом есть system tests, integration tests и т.д.
Пока я слышу только крики про "юнит-тесты" и их неоценимую помощь. Можете начать новую тему: "А вы пишете system tests?"
J>Если продолдать строительную тематику, то очевидно, что приемы и методики тестирования кирпичей и труб совершенно не применимы к тестированию построенного здания целиком.
Как я уже откомментировал, подобный примитив не интересен. Здания — вот уровень, с которого можно что-то обсудить со знающими людьми.
Здравствуйте, matumba, Вы писали:
M>>>Jazzer, у меня тоже есть для вас сюрприз! "маленькие, чётко оговоренные библиотечки" — это СТРОИТЕЛЬНЫЕ БЛОКИ, ничего не значащие сами по себе. Будучи же собранные в систему, они и составляют ту сложную хренотень, которую не так просто протестировать! G>>Неправда. Каждый кирпичик тестируется отдельно...
M>Такой примитивный уровень не интересен.
Так это и есть unit-testing
M>Плюс из моего исходного сообщения пропущены ключевые слова, читайте внимательно.
Я ничего не вырезал.
M>>>Более того, метафора "кирпичей" хороша только в статьях — на деле, взаимодействие и проникновение кода куда сложнее. G>>Это зачастую признак хренового кода. M>Если ваши задачи решают квадратные уравнения, это ещё не повод думать, будто всё на свете так легко поддаётся декомпозиции.
Если что-то сложно поддается декомпозиции, то это не повод не заниматься декомпозицией.
M>>>Если модуль А делает работу, Б её обновляет, при этом модуль В синхронно работает с А и Б, обрабатывая результаты обоих, я бы не стал на вашем месте бросаться это тестировать "юнит-тестами" — рискуете поседеть и всё равно ни черта не решить. G>>Такие случаи находятся за пределами компетенции юнит-тестов.
M>Как уже сказал, другие примитивные случаи не интересны. А судя по крикам студентов "Как, вы не пишете тесты?!?!" начинаешь опасаться за здоровье программирующих — уж не идолопоклонничеством ли они занимаются.
Тогда зачем ты тут пишешь? Тема о юнит-тестах, а тебе она не интересна и ты пишешь о чем-то своем.
M>>>Увлечение новым buzzword "TDD" — это ещё один манёвр известного "огонь и движение". G>>TDD, это не тесты, TDD — методика дизайна кода, причем вполне хорошо работающая при детальном дизайне. M>Спускаться к лингвистическим дебрям — это да, признак умного и квалифицированного оппонента.
Ты просто не понимаешь TDD.
M>TDD — buzzword, хорошо работающее на примитивных задачах. Сложные задачи продумать до деталей нереально, а когда твердолобые таки начинают писать спеки раньше программы, получается тот самый "исторически сложившийся маразм" в архитектуре. Итеративность — вот ключ разработки. А в такой динамике извините, тесты отдыхают.
Надо декомпозировать любую задачу до примитивных. если этого не делать тогда всегда найдутся проблемы в архитекторах, процессах, инструментах.
Здравствуйте, matumba, Вы писали:
M>Здравствуйте, jazzer, Вы писали:
J>>И Unit Testing — это _только_ о тестировании этих самых блоков.
J>>А то, что ты пытаешься притянуть практику тестирования блоков к тестированию системы в целом — это уже твои проблемы.
M>Капитан Очевидность, вам действительно интересен этот метод? Тогда могу только поздравить, все открытия у вас ещё впереди.
Какой именно метод? Твой (юнит-тесты для системы в целом) — неинтересен. Юнит-тестирование — интересно.
J>>Потому что для тестирования системы в целом есть system tests, integration tests и т.д.
M>Пока я слышу только крики про "юнит-тесты" и их неоценимую помощь. Можете начать новую тему: "А вы пишете system tests?"
Конечно же начни, кто-то мешает?
J>>Если продолдать строительную тематику, то очевидно, что приемы и методики тестирования кирпичей и труб совершенно не применимы к тестированию построенного здания целиком.
M>Как я уже откомментировал, подобный примитив не интересен. Здания — вот уровень, с которого можно что-то обсудить со знающими людьми.
Ради бога. Не лезьте тогда в тему, где обсуждается примитивный уровень.
Здравствуйте, FR, Вы писали:
FR>Можно попробовать по мотивам http://en.wikipedia.org/wiki/QuickCheck сформировать инварианты и гонять на случайных данных и множестве запусков.
И получится тест, который может выдавать разный результат в зависимости от фазы Луны.
... << RSDN@Home 1.2.0 alpha 4 rev. 1227 on Windows Vista 6.1.7100.0>>
Здравствуйте, matumba, Вы писали:
M>Jazzer, у меня тоже есть для вас сюрприз! "маленькие, чётко оговоренные библиотечки" — это СТРОИТЕЛЬНЫЕ БЛОКИ, ничего не значащие сами по себе. Будучи же собранные в систему, они и составляют ту сложную хренотень, которую не так просто протестировать!
"Та сложная хренотень", собранная из библиотечек, юнит-тестами не тестируется по определению. Для этого есть тесты интеграционные и функциональные. Вот только если "хренотень" изначально состоит из модулей, которые делают "фиг-знает-что" (потому что писались на коленке без юнит-тестов), то это уже, увы, не поможет.
AndrewVK,
FR>>Можно попробовать по мотивам http://en.wikipedia.org/wiki/QuickCheck сформировать инварианты и гонять на случайных данных и множестве запусков.
AVK>И получится тест, который может выдавать разный результат в зависимости от фазы Луны.
А почему? Для языков таких как Эрланг и Хаскелл сей тул зарекомендовал себя с самой лучшей сторны: Multicore programming in Erlang
G>>Ты просто не понимаешь TDD.
AVK>Вот что меня всегда радовало, так это то, что все разговоры о TDD всегда заканчиваются этим "аргументом". Ну еще книжки отправляют читать, бывает.
Хорошо ещё не классическим "Ты просто не умеешь их готовить!".
Фактически, мои претензии к TDD состоят в их примитивности и РАЗДУТОЙ ШУМИХЕ вокруг них. Ни один _ля "профессионал" (коими кишит этот форум) никогда не делает оговорок об узкой применимости TDD — все только и умеют тыкать окружающих носом: "Как?! Вы не пишете тесты?!" (читай: ну вы и _удаки!) Да, возвышать себя унижая других — это древнее умение.
Кроме того, НИКТО не задаёт вопросов про системное тестирование, многопоточное, транзакционное.... Ухватились за то, на что мозгов хватило, и давай пальцы на форумах гнуть! Надоело — вот и написал.
Здравствуйте, matumba, Вы писали:
G>>>Ты просто не понимаешь TDD.
AVK>>Вот что меня всегда радовало, так это то, что все разговоры о TDD всегда заканчиваются этим "аргументом". Ну еще книжки отправляют читать, бывает.
M> Хорошо ещё не классическим "Ты просто не умеешь их готовить!".
Не надоело бравировать своим непониманием?
M>Фактически, мои претензии к TDD состоят в их примитивности и РАЗДУТОЙ ШУМИХЕ вокруг них. Ни один _ля "профессионал" (коими кишит этот форум) никогда не делает оговорок об узкой применимости TDD — все только и умеют тыкать окружающих носом: "Как?! Вы не пишете тесты?!"
Да ты че?
А ты не думал что проверить корректность программы на динамическом языке можно только тестированием?
Не приуменьшай важность тестирования как такового. А также разберись что такое TDD.
M>(читай: ну вы и _удаки!)
Если хочешь — читай так.
M>Да, возвышать себя унижая других — это древнее умение.
Ты это отлично показываешь.
M>Кроме того, НИКТО не задаёт вопросов про системное тестирование, многопоточное, транзакционное.... Ухватились за то, на что мозгов хватило, и давай пальцы на форумах гнуть! Надоело — вот и написал.
А с чего ты взял что "многопоточное" важнее тестирования?
M>> Хорошо ещё не классическим "Ты просто не умеешь их готовить!". G>Не надоело бравировать своим непониманием?
Читаем ещё раз: M>>Да, возвышать себя унижая других — это древнее умение.
TDD очевиден как котлета, ЧТО вы в нём хотите обсудить? Флейма уже на 10 страниц, но вы упорно с видом мудреца впариваете 2х2=4.
G>А ты не думал что проверить корректность программы на динамическом языке можно только тестированием?
Ну вот, теперь ещё и динамика... А прежде чем вообще начинать темы про TDD, вы не удосужились очертить ЗАДАЧИ, которые вы им успешно решаете?
Пока я только слышу общие (а значит общеприменимые) и удивительные по настырности советы "пишите тесты!".
Кстати, "динамические языки" — не такая большая ниша, так что пусть решают свои проблемы сами, без рекламы TDD.
G>Не приуменьшай важность тестирования как такового. А также разберись что такое TDD.
См про "2х2".
Никто тесты не отрицает, но выпячивать их как панацею — встречается буквально в каждой первой статье о TDD.
Что забавно, Джоэл (в своих 12 признаках) даже словом не обмолвился о TDD. Есть повод задуматься.
M>>Кроме того, НИКТО не задаёт вопросов про системное тестирование, многопоточное, транзакционное.... Ухватились за то, на что мозгов хватило, и давай пальцы на форумах гнуть! Надоело — вот и написал. G>А с чего ты взял что "многопоточное" важнее тестирования?
Это твои слова (туповатый метод спора, согласись?). Тестирование ЛЮБОГО вида важно, каждое в своей задаче. Но раз мы пишем весьма сложные задачи, то тесты а-ля "правильное вычисление квадратного корня" просто примитив по ср. с задачами самой системы.
Лучший тестер по прежнему остаётся человек.
Здравствуйте, matumba, Вы писали:
M>>> Хорошо ещё не классическим "Ты просто не умеешь их готовить!". G>>Не надоело бравировать своим непониманием?
M>Читаем ещё раз: M>>Да, возвышать себя унижая других — это древнее умение. M>TDD очевиден как котлета, ЧТО вы в нём хотите обсудить? Флейма уже на 10 страниц, но вы упорно с видом мудреца впариваете 2х2=4.
Я уже все в этой теме обсудил, и это не я с видом мудреца доказываю что тесты неважны.
G>>А ты не думал что проверить корректность программы на динамическом языке можно только тестированием?
M>Ну вот, теперь ещё и динамика... А прежде чем вообще начинать темы про TDD, вы не удосужились очертить ЗАДАЧИ, которые вы им успешно решаете?
Задача для тестов одна — проверка корректности кода.
Есть случая когда тестирование излишне — когда коррекность проверяется статически — с помощью системы типов или DbC.
Есть случаи, когда проверка корректности программы недетерминирована — такое возникает с асинхроных системах, в таком случае тесты неочень эффективны.
M>Пока я только слышу общие (а значит общеприменимые) и удивительные по настырности советы "пишите тесты!".
Потому что написание тестов, особенно до написания кода, помогает лучше понять как система должна работать.
M>Кстати, "динамические языки" — не такая большая ниша, так что пусть решают свои проблемы сами, без рекламы TDD.
Чем тебе TDD не угодил?
G>>Не приуменьшай важность тестирования как такового. А также разберись что такое TDD. M>Никто тесты не отрицает, но выпячивать их как панацею — встречается буквально в каждой первой статье о TDD.
Ну так не читай такой булшит, тебя же никто не заставляет.
M>Что забавно, Джоэл (в своих 12 признаках) даже словом не обмолвился о TDD. Есть повод задуматься.
А куча народу пишет только о TDD и ниче.
M>Лучший тестер по прежнему остаётся человек.
С чего бы?
Человек ошибается, а компьютер — нет.
unit-тесты и интеграционное тестирование, это как раз работа с которой компьютер справляется гораздо лучше человека.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, AndrewVK, Вы писали:
AVK>>И получится тест, который может выдавать разный результат в зависимости от фазы Луны.
FR>Угу а статистическая физика — лженаука
Статистической физика называется не потому что её законы выведены из статистических исследований, а потому что статистическое поведение системы почти всегда совпадает с результатами теоретических исследований.
Здравствуйте, gandjustas, Вы писали:
G>Статистической физика называется не потому что её законы выведены из статистических исследований, а потому что статистическое поведение системы почти всегда совпадает с результатами теоретических исследований.
M>>Лучший тестер по прежнему остаётся человек. G>С чего бы? G>Человек ошибается, а компьютер — нет. G>unit-тесты и интеграционное тестирование, это как раз работа с которой компьютер справляется гораздо лучше человека.
Это в том случае, когда юнит-тесты и тесты интеграции представлены в виде проверяемых компьютером контрактов.
Читай — выражены в виде типов.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
M>>>Лучший тестер по прежнему остаётся человек. G>>С чего бы? G>>Человек ошибается, а компьютер — нет. G>>unit-тесты и интеграционное тестирование, это как раз работа с которой компьютер справляется гораздо лучше человека.
T>Это в том случае, когда юнит-тесты и тесты интеграции представлены в виде проверяемых компьютером контрактов.
Я про это чуть выше написал.
С задачей проверки контрактов компьютер тоже справляется лучше.
T>Читай — выражены в виде типов.
Это не единственный способ выражения контрактов.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
