Здравствуйте, Nuzhny, Вы писали:
N>Например, тесты OpenCV.
Да, именно такие тесты я и имел в виду.
Они, безусловно, полезны, но приходится выбирать — либо писать тесты, либо реализовывать полезный функционал. Время не резиновое.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Возможно там, где методы примитивные и меняются по дцать раз на дню, юнит-тесты будут более уместны.
Вот как раз думаю, что юнит-тесты будут уместнее для стабильной кодовой базы, как подстраховка от кривого рефакторинга.
Для часто меняющегося кода они ни к чему, тут лучше интеграционные тесты.
Здравствуйте, Sharov, Вы писали:
S>Вот как раз думаю, что юнит-тесты будут уместнее для стабильной кодовой базы, как подстраховка от кривого рефакторинга. S>Для часто меняющегося кода они ни к чему, тут лучше интеграционные тесты.
Именно так. Главная цель unit tests — автоматическое выявление regression issues между релизами. Очень удобно, практично. Но писать тесты до реализации — it's ridiculous
Здравствуйте, ArtDenis, Вы писали:
AD>Здравствуйте, Grienders, Вы писали:
G>>Наконец-то я понял, зачем нужны тесты. Наверное, дзен пришел Я раньше никогда их не писал, зачем? Все на глаз.
AD>Стареешь просто. Вот мудрость на тебя и нисходит
Ну да, молодёжь просто учат уже по-другому, говорят что без тестов никак. Вот и лупят бездумно по писанному, без духовного понимания
Здравствуйте, Mr.Delphist, Вы писали:
MD>Ну да, молодёжь просто учат уже по-другому, говорят что без тестов никак. Вот и лупят бездумно по писанному, без духовного понимания
Времена меняются, однако. Сейчас к коду проекта могут допустить толпу начинающих или не очень разбирающихся в теме программистов. Так вот, после них проект должен не только выжить, но и получить качественный функционал. Как это сделать без тестов — хз.
K>Лень разбираться, что это такое. Посмотрел по верхам. K>Оно что, случайные наборы данных генерирует?
В целом — да. В том числе сложные структуры. Плюс может разбросать по frequnecy distribution. Самое главное: когда тест валится, оно старается найти минимальный набор данных, на котором тест валится.
Конкретно Quickcheck (эрланговская реализация) еще умеет тестировать state-машины и параллельные вызовы.
Здравствуйте, mapnik, Вы писали:
M>Ну это ваша субъективная точка зрения. M>При этом вам не кажется странным что при этом большинство компаний и инженеров не используют TDD и при этом разрабатывают ПО в достаточно сжатые сроки?
Здравствуйте, landerhigh, Вы писали:
L>Это хорошо. L>А если требуется работающее ПО?
Оно в массе своей написано без TDD. Unix и его приемники FreeBsd/OSX, Windows, GCC, Oracle и др. Лучше назовите мне проекты где использовалась TDD?
Уверен после долгих потуг всплывет какая нибудь занюханная лизинговая система на java или нечто подобное.
Здравствуйте, mapnik, Вы писали:
L>>Это хорошо. L>>А если требуется работающее ПО?
M>Оно в массе своей написано без TDD. Unix и его приемники FreeBsd/OSX, Windows, GCC, Oracle и др. Лучше назовите мне проекты где использовалась TDD? M>Уверен после долгих потуг всплывет какая нибудь занюханная лизинговая система на java или нечто подобное.
Я даже занюханной лизинговой системы не назову. На ум приходит только одна небольшая и никому не известная SCADA система
Здравствуйте, Nuzhny, Вы писали:
N> Я не знаю, как по-другому организовать процесс.
Это всё замечательно, но на 90% не имеет IT специфики(анализ проблемы-обзор имеющихся решений-выводы... это применимо к любой деятельности), а остальное — не имеет отношения к TDD.
Генерация тестовых наборов данных и прогон с ними — это вообще функциональное тестирование(или системное?), там всё уже должно "в общем" работать. Генерировать их до или после конкретной реализации вообще не важно.
Здравствуйте, abibok, Вы писали:
G>>А сейчас — накалял что-нибудь, написал тест, проходит — хорошо.
A>Следующий этап просветления — сначала писать тесты, и только потом калякать.
1. Наконец-то я понял, зачем нужны тесты. Наверное, дзен пришел Я раньше никогда их не писал, зачем? Все на глаз.
А сейчас — накалял что-нибудь, написал тест, проходит — хорошо.
2. Наконец-то я понял, зачем нужна статическая типизация и компилятор. Наверное, дзен пришел Я раньше никогда не использовал, зачем? Все на хештаблицах. А сейчас — накалял что-нибудь, запустил компилятор, проходит — хорошо. И тестов писать меньше надо!
3. Наконец-то я понял, зачем нужно функциональное программирование. Наверное, дзен пришел Я раньше никогда не использовал, зачем? Все есть объекты. А сейчас — накалял чистую функцию — хорошо. Про тесты почти совсем забыл.
Насколько я понял, одни генерируют случайные входные данные, другие же формально доказывают что входных данных удовлетворяющих предусловиям и которые ломают заданные инварианты и постусловия нет (либо есть) — это вообще-то разного порядка задачи
M>>Очень полезная штука. Особенно полезна, когда есть разные комбинации данных, тесты для которых сложно написать/предугадать вручную, особенно из-за комбинаторного взрыва. Например, ребята тут: http://envisage-project.eu/proving-android-java-and-python-sorting-algorithm-is-broken-and-how-to-fix-it/ по сути занимаются тем же.
EP>Насколько я понял, одни генерируют случайные входные данные, другие же формально доказывают что входных данных удовлетворяющих предусловиям и которые ломают заданные инварианты и постусловия нет (либо есть) — это вообще-то разного порядка задачи
Ну, начинали они именно с генерации случайных входных данных:
The testgenerator on our website exploits this problem. It generates an input array with many short runs – too short, in the sense that they do not satisfy the invariant – which eventually causes TimSort to crash.
А то, как они доказывали — это как раз то, что Quickchek делает (в явном виде — с pre-/pos-conditions для верификации state machines, например):
KeY is a deductive verification platform for sequential Java and JavaCard applications. It allows to prove the correctness of programs with respect to a given specification. Roughly speaking, a specification consists of a precondition, also called requires clause and a postcondition, also called ensures clause.
Ну и по сути они генерируют возможные способы:
KeY performs symbolic execution of the method under verification, that is, it executes it with symbolic values so that all possible execution paths are taken into account.
MVK>3. Наконец-то я понял, зачем нужно функциональное программирование. Наверное, дзен пришел Я раньше никогда не использовал, зачем? Все есть объекты. А сейчас — накалял чистую функцию — хорошо. Про тесты почти совсем забыл.
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, abibok, Вы писали:
A>>Следующий этап просветления — сначала писать тесты, и только потом калякать.
DM>Пробовал — перестал работать intellisense.
Resharper: Alt+Enter на красненьком -> Create Method/Property/Classs/Interface/etc. Все будет создано в лучшем виде, в соответствии с контекстом (сигнатурой, например). Названия вводятся ровно один раз, также как и при подходе "Calyakanie First". Но API тестируемого кода сразу продумывается, и получается юзабельным. А иначе, бывает, напишешь класс, а потом мучительно рефакторишь его, чтобы привести в пригодный для реального применения вид.
Здравствуйте, Крякозавр, Вы писали:
К>Но API тестируемого кода сразу продумывается, и получается юзабельным.
Юзабельным в каком смысле? В смысле "может быть применено автором для реальной задачи" — да. А вот в смысле "может быть использовано другими программистами без особых проблем" — вряд ли.
Приведу кривую аналогию. Допустим, вы разрабатываете холодильник. Тесты гарантируют, что холодильник помещается в квартиру и может подключаться к стандартной розетке (что в общем тоже неплохо). Но вот обычные люди в нем путаются. Потому что если потянуть ручку холодильника на себя, у него отсоединяется компрессор (для дальнейшего обслуживания), для открывания ручку нужно тянуть вверх, а температура задается с использованием азбуки морзе и единственной кнопки.
Для создания хорошего API нужно применять методологии из дисциплин, связаных с usability. Например, нужно понимать, что пользователи инструмента (не важно, холодильника или API) создают ментальные модели (mental model) этого инструмента. Модели не обязательно должны быть полны и точны. Достаточно того, что модель полезна (например, не нужно знать всю физику за выключателем света или краном воды). Но на границах применимости модели пользователь будет делать ошибки (потому что он следует модели, а она не верна). Вот здесь возникает проблема. Автор API не общается непосредственно с пользователем API. Пользователь API строит свою модель только на основе этого API (system image называется в ux). И в пользовательской модели могут быть отличия от авторской (в The design of everyday things есть очень хорошая картинка, у кого есть доступ — смотрите там). Тестирование обычно выполняется автором и не учитывает подобного различия.
Если заботиться о действительно юзабельном API, то его характеристиками будут:
Как минимум одна простая ментальная модель (вы можете объяснить свое API за 5-10 минут новому программисту).
Отсутствие других (заведомо неверных) моделей. Как минимум тех, которые могут быть видны невооруженным взглядом.
Подсказки и указания на модель (signifiers). Включая null/not null и прочие важные моменты, которые позволяют отсечь неверные модели.
Уважительное и продуктивное поведение в случае ошибок (resilience). Информации должно быть достаточно, чтобы можно было легко (5-10 минут, без отладки) о несоответствии ментальной модели системе.
Тесты обычно не помогают в этом. Автор (инжинер) думает только о функциональных характеристиках, о выполнении "функциональной" задачи. Очень часто он даже не понимает психологических особенностей других пользователей его API (других программистов). Тесты улучшают характеристики (код становится хоть чуть-чуть полезен), но не более того.
Я знаю только один способ делать юзабельный (уже в широком) смысле API. Это писать документацию. Хотя бы на уровне чуть выше "простой отписки". Это заставляет инженера проговорить "вслух" как минимум одну ментальную модель. Выяснить неточности в ней. Объем документации позволяет оценить "простоту" модели. В документации можно расставить signifiers (и правильно выделить!), чтобы направить пользователя API в нужное русло. Немного помогает и созданию хорошего поведения в случае ошибок ("ну получил пользователь эту ошибку, что осознанного он может с ней сделать? Достаточно ли ему информации?"). С "отсутствием других моделей" документация помогает не так сильно. Здесь нужно уметь читать свое творчество буквально и пытаться его интерпретировать неправильно (хотя при тренировке приходит и это). Зато оказываются очень полезны ревью кода. Ревьювер специально читает "быстро" и использует первую попавшуюся интуитивную модель.
Из практики. Фокус на ментальных моделях (ну ок, на _хорошей_ документации, она чуть слабее) позволяет писать хорошее API и приложения. Большинство ошибок простые и понятные, правятся за 5-10 минут. В результате в релиз идет приложение без открытых багов (да, именно без багов). Джуниоры растут очень быстро, если их заставлять писать документацию и проверять ее. И ошибок мало допускают . Очень часто продуманная модель служит и тому, что получившийся API можно использовать в реальных задачах (хотя можно и тесты).
Еще пара бессистемных мыслей про ментальные модели.
Мимикрия под другие ментальные модели — плохо. Или вы реализуете какое-то API полностью, или стремитесь дистанциироваться от него. Иначе из-за несоответствия моделей программисты будут часто допускать ошибки. Например, если вы пишете XML и используете namespace, то вы должны поддерживать все форматы указания этого namespace (default на документе, с префиксами (причем в виде любых корректных имен), с указанием на каждом элементе и т.п.). Я сам видел, как некоторые "гении" корректно обрабатывали namespace только если это default namespace на всем XML (и не факт, что обрабатывали, может, он для красоты там был, я не проверял).
Функциональное программирование хорошо именно своей простой ментальной моделью. "Дали данные на вход функции, получили результат. При этом кроме появления нового результата в мире ничего не изменилось". Сравните с императивным программированием. Можете его семантику так же коротко описать?
Я раньше никогда их не писал, зачем? Все на глаз. 
