M>>Именно. Ты его увидел после того, как его тебе уже показали. Ты готов его увидеть сразу и написать тест для него? S>Для словаря сходу не додумался бы.
О чем и речь.
S>Для арифметический операций или ф-ий да.
Но не додумался бы до чего-нибудь еще.
Программисты не идеальные люди, и далеко не все варианты помнят и/или тестируют. Property-based testing вполне помогает выявить вот такие забытые или неучтённые вещи. Или далеко неочевидные вещи. Тут есть такой пример (с 37 минут с копейками), особенно Bug #4.
Правда, не так легко научиться им пользоваться Я когда-то неплохо умел, но теперь всё, забыл.
M>> Я когда-то неплохо умел, но теперь всё, забыл.
S>Тут какие-то особые навыки или знания нужны?
Навык: как увидеть тестируемое свойство программы и как написать к нему генератор и проверку. Иногда достаточно тестов типа
— для целых чисел N больше нуля функция F(N) не должна ломаться
— для сгенерированных данных D должно выполняться D == deserialize(serialize(D))
Для более сложных сценариев надо во-первых понять, что именно тестируешь, и как не превратить тест в повторение логики в тестируемой функции. Как например в первой моей ссылке, где чувак сначала придумал как генерировать данные, а потом прогонять тест.
Здравствуйте, Mamut, Вы писали:
M>Я тебе уже конкретно ответил. Но тебе мои ответы не нравятся.
Почему не нравятся? Нравятся. Только ответы не о том, о чём я спрашиваю.
M>Более того, у тебя и программисты идеальные и пишут все тесты, и какие-то отдельные организации проверяют работу программистов, и так далее и тому подобное.
А вы думаете в таких областях как ядерная энергетика, космитечкая техника, гражданское авиастроение, железные дороги и т.п. сторонние организации работу програмистов не проверяют?
M>>Я тебе уже конкретно ответил. Но тебе мои ответы не нравятся. BFE>Почему не нравятся? Нравятся. Только ответы не о том, о чём я спрашиваю.
Потому что ты спрашиваешь исключительно один вопрос, про рандомные данные.
M>>Более того, у тебя и программисты идеальные и пишут все тесты, и какие-то отдельные организации проверяют работу программистов, и так далее и тому подобное. BFE>А вы думаете в таких областях как ядерная энергетика, космитечкая техника, гражданское авиастроение, железные дороги и т.п. сторонние организации работу програмистов не проверяют?
1. Я думаю, что подавляющее большинство программистов работают не в этих областях.
2. В этих областях говна столько же, как и везде, потому что люди одинаковые. Мы это говно редко видим только потому что про это говно мало кто говорит. Вот пример из такой же важной индустрии как автомобилестроение (с 19 минуты): https://youtu.be/zi0rHwfiX1Q?t=1137
Здравствуйте, Mamut, Вы писали:
M>2. В этих областях говна столько же, как и везде, потому что люди одинаковые. Мы это говно редко видим только потому что про это говно мало кто говорит. Вот пример из такой же важной индустрии как автомобилестроение (с 19 минуты): https://youtu.be/zi0rHwfiX1Q?t=1137
Вот согласен, при чем там ошибки случаются далеко не только в софте, а и конструкционные.
Как и с любым другим подходом, надо либо им пользоваться (и тогда помнить, как и что), либо нет — и тогда нужны будут особые навыки "быстро и правильно научиться" (это ключевой навык для любого современного инженера).
Здравствуйте, B0FEE664, Вы писали:
M>>Более того, у тебя и программисты идеальные и пишут все тесты, и какие-то отдельные организации проверяют работу программистов, и так далее и тому подобное. BFE>А вы думаете в таких областях как ядерная энергетика, космитечкая техника, гражданское авиастроение, железные дороги и т.п. сторонние организации работу програмистов не проверяют?
Проверяют. Проверяют именно работу программистов. А не то, что они там напрограммировали.
Я когда-то неплохо умел, но теперь всё, забыл.
