"Вигнер удивлялся тому, что математика так непостижимо эффективна в описании физики нашей Вселенной. "
Математика - инструмент, созданный для описания вселенной. Удивляться, что она подходит для этого - все равно, что удивляться, что молотком удобно забивать гвозди.
Слышал про эксперименты с переворачиванием изображения. Там - да, все через некоторое время приходит в норму. Причем, после снятия переворачивающих очков избражение некоторое время кажется перевернутым.
Зеркало не меняет право и лево. Левая рука как была в реальности слева от тела набллюдателя, так и в отражении остается слева от тела наблюдателя. Другое дело, что у человека, стоящего напротив, его левая рука справа от наблюдателя. И, глядя на отражение, мы представляем стоящего напротив человека и думаем, что лево и право поменялось.Ааналогично с остальными примерами: мы ожидаем увидеть повернутый к нам текст, ожидаем вращение ближней точки в другую сторону. Т.е., это чисто психологичейский эффект.
А, поскольку стоящий напротив человек не переворочивается с ного на голову, то и "смены верха и низа" мы в зеркале не видим.
Это понятно, но он просто получит неправильное количество секунд (или чего-то еще), по ним вычислит неправильное количество минут-часов-дней-месяцев и т.д. Это не имеет отношения к вопросу про количество дней в месяце.
А так — да, можно к списку в статье добавить такую проблему:
— То, что программист считает временем — не обязательно им является.
Какое отношение все это имеет к количеству дней в месяце?
Это даже не неверная работа со временем, а замена реального времени каким-то левым параметром.
Вот этого не понял.
Ну, проработала она физически 3 недели из месяца — что это меняет? Если ее спросят (условно) «Что ты делал месяц назад?» ей же дату календарную определять, а не по своей фактической работе.
Тут же дело не в том, что это вес коробки, а в том, заметит разработчик это граничное условие или нет.
Хорошо, если условие такое очевидное — 0. А если 3,14? Или -1?
Да, в коде (или в ТЗ) будет деление (например) на x+1. Если разработчик это заметит, то он и в коде проверку напишет и в тесте. Если нет — ни там, ни там. И это не зависит от того, что он пишет сначала — код или тесты.
Т.е., тесты, написанные разработчиком, не найдут его ошибки.
А значит, нужно независимое от разработчика тестирование.
Вот все, что я хочу сказать.
Но, так-то, да. Хорошо бы сначала написать подробное ТЗ со спецификациями, потом тесты, потом код, потом документацию. Где-то в идеальном мире…
Так о том и речь. Разработчик — не выявит. А тестировщик — вполне может.
Поэтому требовать от разработчика написания тестов именно для проверки новой функциональности — бессмыслено.
Пример: допустим, у нас есть вес коробки, на который мы где-то в коде делим.
Если разработчик сообразил, что кто-то может указать там 0, то он и проверку в коде сделает и тест с 0 напишет.
Если не сообразил — не сделает ни того, ни другого.
Речь не о том, положительные мы случаи тестируем или отрицательные, а о том, что разработчик о них знает и в коде обработал. Неожиданные для себя варианты он не проверит.
Я не спорю с полезностью написания тестов до кода.
Я только про то, что тесты все равно будут написаны только на те случаи, что обработаны в коде. Не выявят ошибок, неожиданных для программиста.
Они не просто не умеют тестировать. Они тестируют то, что работает.
Все дело именно в том, что разраотчик писал этот код. Если бы ему пришла в голову мысль, что здесь что-то может пойти не так, он бы поправил это в коде. А, если такая мысль при разработке не пришла, то почему она придет при тестировании?
Разработчики должны писать внутренние тесты. Но они не для проверки, а для будущей разработки — рефакторинга, доработки.
А внешние тесты, для проверки должен и писать внешний человек — тестировщик.
Вот именно, "если будем рассматривать". А кто мог их рассматривать миллиард лет назад. Согласно ему же.
Согласно тов. Нагарджуна объектов не существует. Какая у них площадь?
"Вигнер удивлялся тому, что математика так непостижимо эффективна в описании физики нашей Вселенной. "
Математика - инструмент, созданный для описания вселенной. Удивляться, что она подходит для этого - все равно, что удивляться, что молотком удобно забивать гвозди.
Слышал про эксперименты с переворачиванием изображения. Там - да, все через некоторое время приходит в норму. Причем, после снятия переворачивающих очков избражение некоторое время кажется перевернутым.
Зеркало не меняет право и лево. Левая рука как была в реальности слева от тела набллюдателя, так и в отражении остается слева от тела наблюдателя. Другое дело, что у человека, стоящего напротив, его левая рука справа от наблюдателя. И, глядя на отражение, мы представляем стоящего напротив человека и думаем, что лево и право поменялось.Ааналогично с остальными примерами: мы ожидаем увидеть повернутый к нам текст, ожидаем вращение ближней точки в другую сторону. Т.е., это чисто психологичейский эффект.
А, поскольку стоящий напротив человек не переворочивается с ного на голову, то и "смены верха и низа" мы в зеркале не видим.
Например, 2 задача легко получается из 1-ой:
Чему учит приведенный пример — непонятно.
Мы же сейчас не об этих примерах, а о влиянии простоя. С этими примерами я не спорю, хотя они тоже довольно специфические.
Может, но с количеством дней в месяце эти причины не связаны.
А так — да, можно к списку в статье добавить такую проблему:
— То, что программист считает временем — не обязательно им является.
Это даже не неверная работа со временем, а замена реального времени каким-то левым параметром.
Ну, проработала она физически 3 недели из месяца — что это меняет? Если ее спросят (условно) «Что ты делал месяц назад?» ей же дату календарную определять, а не по своей фактической работе.
А с этим что не так?
Хорошо, если условие такое очевидное — 0. А если 3,14? Или -1?
Да, в коде (или в ТЗ) будет деление (например) на x+1. Если разработчик это заметит, то он и в коде проверку напишет и в тесте. Если нет — ни там, ни там. И это не зависит от того, что он пишет сначала — код или тесты.
Т.е., тесты, написанные разработчиком, не найдут его ошибки.
А значит, нужно независимое от разработчика тестирование.
Вот все, что я хочу сказать.
Но, так-то, да. Хорошо бы сначала написать подробное ТЗ со спецификациями, потом тесты, потом код, потом документацию. Где-то в идеальном мире…
В спецификации написано — «вес коробки». Всем же известно, что в реальной жизни вес положительный. Так?
Поэтому требовать от разработчика написания тестов именно для проверки новой функциональности — бессмыслено.
Если разработчик сообразил, что кто-то может указать там 0, то он и проверку в коде сделает и тест с 0 напишет.
Если не сообразил — не сделает ни того, ни другого.
Я только про то, что тесты все равно будут написаны только на те случаи, что обработаны в коде. Не выявят ошибок, неожиданных для программиста.
Если сначала написать тесты, то они будут тестировать то, что будет работать. То, что не будет — все равно останется за бортом.
Они не просто не умеют тестировать. Они тестируют то, что работает.
Все дело именно в том, что разраотчик писал этот код. Если бы ему пришла в голову мысль, что здесь что-то может пойти не так, он бы поправил это в коде. А, если такая мысль при разработке не пришла, то почему она придет при тестировании?
Разработчики должны писать внутренние тесты. Но они не для проверки, а для будущей разработки — рефакторинга, доработки.
А внешние тесты, для проверки должен и писать внешний человек — тестировщик.