Comments 10
1. Камень прилетает в лоб.
2. Автор машины не знает про устройство смыва в бачке — механическая рука опустится вниз, колено не там должно быть.
3. Зачем вентилятор — я не понял. Сдуть тряпочку, которая закрывает обзор кролику?
4. Кролик прыгнет, а не побежит.
5. Хана телевизору при падении подставки для свечи.
6. Так и вижу, как рыбка насаживается на гвоздь.
7. Брызги во все стороны.
8. Интересно посмотреть на реакцию обрызганного кота, который не пытался ловить рыбку в пакетике.
9. Вряд ли усилий хватит для нажатия, но вот сопротивления нажатию хватит для переворачивания.
P. S.
Помнится, в одном сериале про заучекТБВ же?
Вы явно не играли в оригинал The Incredible Machine. Там есть несколько нюансов (с).
- У качелей фиксированная сила, прилагаемая к предмету на второй стороне качелей, поэтому правильно выбранный предмет полетит со строго заданной скоростью. (Правда, в случае конкретно TIM он полетит в сторону телевизора и разобьет его. :))
- Рука приделана к палке, которая поднимается вверх с приводом от весов (и там по идее строго слайдер, т.е. одна степень свободы).
- Да, точнее, приподнять её, чтобы кролик увидел морковку.
- Не хватает клетки и колеса, а также приводного ремня между транспортером и колесом. Иначе кролик действительно упрыгает с транспортера. Но эффект будет все-таки, за счет того, что транспортер под кроликом провернется.
- С этой стороны телевизор не разобьется, а отпрыгнувшая свечка прилетит аккурат коту по голове, заставив того ломануться вперед без всякой рыбы в аквариуме.
- Решается укорочением плеча, на котором висит гвоздь. Возможно, машина не совсем в масштабе. Кроме того, рыба в шарике — объект относительно мобильный, может и пронесет.
- Ага, и телеку хана третий раз — закоротит.
- Кстати да, кот реагирует на рыбку ВНЕ аквариума, т.е. чтобы активировать кота, аквариум с рыбой надо разбить. Но это не проблема, свечка активирует кота лучше.
- Точка приложения силы достаточно высоко, т.е. усилий на нажатие таки хватит. Но эффект будет явно большой БУМ, а не работающий телевизор. :)
Меня, как программиста, подобные сложносочинённые тесты напрягают. Я мечтаю, чтобы тестировщики как можно точнее локализовали ошибку, а тут будешь только знать, что в системе из 50 звеньев что-то пошло не так — и ищи, где...
Зато у такого теста отличная воспроизводимость — можно любое число раз пройти всю цепочку в отладчике.
Спасибо. Объяснить, что будет с тестировщиком, предложившим подобное? Правильно, он пойдёт воспроизводить баг заново, пока не напишет нормальный тикет.
Итого, ему всё равно придётся делать короткие тесты — т.е. выполнять вдвое больше работы.
Написание подобной цепочки оправдано в одном случае: прога отлажена до упора, новый функционал в неё не вносится — а значит, вероятность поломки минимальна (и можно не делать коротких тестов, пока всё не сломается).
Ну и более-менее приемлем вариант "написать длинный тест и проверять результат на каждом шаге". Он позволяет малой кровью изолировать баг (у кого тестирование организовано на виртуалке — может быть, можно отдать программистам систему в состоянии "сейчас сломается"). Но тут опять же неприятный момент — когда система дорабатывается и её поведение меняется.
Не надо проверять результат на каждом шаге, пока ничего не сломалось в целом, в этом нет смысла. Вот когда итог не сошелся — тогда можно уже смотреть промежуточные результаты. Первый шаг, на котором произошла ошибка, и станет потом обычным тестом.
Значит, такая ошибка не будет ловиться этим семейством тестов. Печально, конечно — но это просто означает что надо писать разные тесты, а не гонять по кругу один и тот же.
Тем не менее, вероятность появления четной ошибки в такой цепочке довольно низкая — благодаря тому что цепочка составляется из библиотек сторонних производителей (т.е. писавшихся не тем же самым программистом, который писал тестируемую функцию).
The incredible machine или мой самый лучший тест