Здравствуйте, К Тёте, Вы писали:
КТ>Когда нет — придумывать. Если невозможно придумать, то — увы. Но я в жизни не поверю, что весь код состоит из функций, которые невозможно описать, как они работают. Для тех, что описуемы, тесты должны покрывать описание, а не то, как код работает. Например, какой-нибудь код, который убирает дубликаты из дерева разбора. Эти деревья можно нагенерить тоннами и проверить код на бОльшем количестве вариантов, чем assert(remove_duplicates([a, b, a]) == [a, b]).
в алгоритмах есть можно сказать "точки разрыва" — когда поведение меняется. то есть есть ф-ия, например, которая число печатает. переход от одной цифры к двум — такая "тока разрыва непрерывности решения". да, мы можем нагенерировать тонну, там, списков для проверки правильно работы убирания дубликатов, но разумнее специфицировать это примерно так:

[] -> [] // это спецификация на "невалидные данные"
[a] -> [a] // на данные, которые не нужно обрабатывать
[a, a] -> [a] // простейший пример
[a, a, a] -> [a] // а то вдруг там иф будет стоять, который пару схлопнет, а тройку нет
[a, b, a] -> [a, b] // дубликат, стоящий неподряд
[b, a, b, a] -> [b, a] // два дубликата неподряд
[a, b, c, b] -> [a, b, c] // убираем не первую букву (а то в остальных тестах она у нас че-то первая стоит)

минимальный код, который будет проходить эти тесты, должен будет убирать дубликаты по-нормальному

Здравствуйте, К Тёте, Вы писали:
КТ>Когда нет — придумывать. Если невозможно придумать, то — увы. Но я в жизни не поверю, что весь код состоит из функций, которые невозможно описать, как они работают. Для тех, что описуемы, тесты должны покрывать описание, а не то, как код работает. Например, какой-нибудь код, который убирает дубликаты из дерева разбора. Эти деревья можно нагенерить тоннами и проверить код на бОльшем количестве вариантов, чем assert(remove_duplicates([a, b, a]) == [a, b]).
в алгоритмах есть можно сказать "точки разрыва" — когда поведение меняется. то есть есть ф-ия, например, которая число печатает. переход от одной цифры к двум — такая "тока разрыва непрерывности решения". да, мы можем нагенерировать тонну, там, списков для проверки правильно работы убирания дубликатов, но разумнее специфицировать это примерно так:

[] -> [] // это спецификация на "невалидные данные"
[a] -> [a] // на данные, которые не нужно обрабатывать
[a, a] -> [a] // простейший пример
[a, a, a] -> [a] // а то вдруг там иф будет стоять, который пару схлопнет, а тройку нет
[a, b, a] -> [a, b] // дубликат, стоящий неподряд
[b, a, b, a] -> [b, a] // два дубликата неподряд
[a, b, c, b] -> [a, b, c] // убираем не первую букву (а то в остальных тестах она у нас че-то первая стоит)

минимальный код, который будет проходить эти тесты, должен будет убирать дубликаты по-нормальному

кстати, тест [b, a, b, a] -> [b, a] требует не просто убирания дубликатов, а сохранения их исходного порядка. что дает повод нам задуматься — а надо ли оно нам? мы-то знаем, что проще всего реализовать без сохранения порядка. вот почему мы вдруг от задачи "убрать дубликаты" вдруг перешли к вопросу "а сохранить ли порядок" и выяснили это не потом, когда что-то упало и мы в дебагере нашли, что порядок изменился и такие, Васе говорим "а че ты порядок-то поменял, олень? а он такой — "ды ну ты ж сам сказал, что дубликаты убрать надо, я и убрал, про порядок никто ниче не говорил"".