Что Вы думаете о вездесущем “Тесте, Тесте, Тесте!” принцип?

Могло ли быть так, что в более поздние годы разработчики пришли к выводу, что "100% уверенность" на самом деле может быть неверной? Разработка программного обеспечения очень сложна, и несмотря на то, что инструменты развивались на протяжении многих лет, так же, как и наше осознание того, что писать хороший код тяжело. Правда, отладка и автоматизированные юнит-тесты сделали нас более продуктивными, но мы все еще производим ошибки, как и тогда, только сейчас у нас есть различные инструменты, чтобы поймать их.

Вообще-то, я испытал обратное. Если раньше это был случай запуска до тех пор, пока он не сработал, то сейчас я выполняю юнит-тест до тех пор, пока тесты не пройдут... и это, кажется, как минимум разумно обычный переход, насколько я вижу.

Должен сказать, что код, который работал в первый раз только с опечатками, по моему опыту никогда не являлся нормой. Разница в том, что теперь я могу найти проблемы гораздо быстрее, а также обнаружить, если старые проблемы вернутся. Иногда я могу управлять довольно короткими и простыми битами кода без ошибок (и размещение на Stack Overflow улучшило эту возможность), но большими, сложными системами? Черт возьми, нет.

Ответить на заголовок вашей заметки - принцип "тест, тест, тест", на мой взгляд, хороший... но я не связываю это с многократным запуском всей программы. Я ассоциирую это с частым выполнением юнит-тестов. Мне редко приходится использовать отладчик для юнит-тестов - как правило, сбой делает причину достаточно очевидной при проверке, так как тестируется только небольшой объем кода.

Вы можете писать код, который, по вашему мнению, знает на 100%, что он делает и чего не делает, но всегда есть тот крайний случай, о котором вы не подумали, или странное исключение, которое вы не ожидаете. Иногда пробное и ошибочное программирование может быть полезным инструментом, чтобы сузить проблему с помощью отладчиков.

Важно знать, какие инструменты доступны вам, чтобы помочь произвести код с минимальным количеством ошибок.

Я обнаружил, что подход Test-Test помогает мне разрабатывать код. Иногда работа, которая должна быть сделана, слишком сложна, чтобы сделать все это в одном. Тестирование заставляет меня разбивать его на более мелкие части, и по мере того, как я их решаю, я могу сложить их в более крупное целое.

- Я прочитал одну книгу ("TDD на примере" Кента Бека), в которой этот подход "проб и ошибок" действительно кажется крайним: но это больше похоже на "заставить работать юнит-тесты". Тем не менее, я не смог заставить себя закончить эту книгу - редкое явление, тем более, что я действительно надеялся получить лучшее понимание. Тем не менее, совершение очевидно имбецильного кода, который должен быть улучшен позже, заставляет меня дрожать.

Наука: Автоматические тесты имеют свои преимущества. Однако, они не являются той серебряной пулей, за которую себя выдают. Ни один метод теста не достаточен для поиска достаточного количества дефектов, а другие методы имеют более высокую скорость обнаружения.

Интуиция: Наши проблемы - это аспекты, которые становятся все более сложными. Сложность сильно коррелирует с объемом кода, которым мы должны управлять. В этом свете TDD пытается решить проблемы с большим количеством кода , написав еще больше кода .

Преимущества: Теперь мы имеем установившийся формализм для того, чтобы сделать тестирование повторяемым, подотчетным и немедленно документированным. Это определенно выход из ситуации "работает на моей машине" и "странно, вчера сработало, дам вам последнюю DLL-ловушку".

В настоящее время я практикую Test Driven Development (TDD), или, по крайней мере, пишу много юнит-тестов, чтобы проверить, что большинство/весь мой код ведет себя так, как я ожидаю. Такой подход заставляет меня смотреть на свою программу с точки зрения потребителя. Также, по мере написания тестов, я часто думаю о граничных ограничениях, дополнительных сценариях, которые я изначально не предполагал и т.д.

Сейчас я подошел к тому, что боюсь вносить изменения в старые программы, так как боюсь, что что что-то сломаю. Регрессивное тестирование обременительно, по сравнению с запуском набора юнит-тестов.

Я думаю, что преимущество приходит косвенным образом: Когда вы принимаете тесты и юнит-тесты, вы должны написать ваше приложение таким образом, чтобы вы действительно могли писать тесты:

• Классы должны быть написаны таким образом, чтобы вы могли инстанцировать один объект без всего приложения и операционной системы вокруг него, но только несколько вспомогательных объектов. Это означает, что вам нужно минимизировать зависимости и сделать все общение с окружающей системой явным.

• Реализация тестовых примеров означает, что вы должны найти минимальную последовательность команд и вызовов, которая заставит ваш класс сделать что-то значимое. Это часто указывает на неудобные дизайнерские решения, или показывает, что классы очень сложно использовать для определенных целей.

В целом, когда вы принимаете тесты, вы получаете систему, которая имеет минимум взаимозависимостей между своими компонентами, а тестовые примеры служат документацией по использованию ваших компонентов.

Тестирование (выполнение вашей системы) говорит вам что-то о "наличии ошибок, но НЕ об их отсутствии" (afaik этот термин придуман дийкстрой). Он указывает на направление, в котором сила вашего тестового набора является ключом к тестированию: "У вас так много тестовых случаев, что можно сказать, что многих багов не существует. Это означает, что большая часть вашего программного обеспечения работает, как и ожидалось".

Некоторые примеры наличия сильного/мощного набора тестов:

• Большое количество кода выполняется вашими юнит-тестами (традиционный термин покрытия)
• У вас нет ложно-отрицательных тестов (тест, который показывает зеленый цвет, но на самом деле должен быть красным). Ложно-отрицательные тесты - это зло, так как они дают неверное представление о качестве теста. Подробнее о хороших тестерах и ложно-отрицательных тестах см. также blog-entry#1 и blog-entry#2.
• Требования понятны (я видел много случаев, когда автоматизированный тест тест тестировал не то, что нужно, и разработчик неправильно понял требование от бизнеса). Для разработчика было зеленым, но для бизнеса система работала не так, как ожидалось (другой вид ложно-отрицательного примера, но на более высоком уровне).

В некотором смысле правильность программы доказывается только тогда, когда это делается с помощью математических доказательств (которые окупаются только для систем, критичных к жизни, и систем с денежными затратами). Тем не менее, с помощью автоматизированного тестирования можно многого добиться (кроме юнит-тестирования, всегда очень помогло автоматизированное интеграционное тестирование).

Что касается отладки: Я использую отладку так часто, как раньше, но иногда, добавляя в код новую функциональность (мой новый тест-кейс отображается зеленым цветом), я ломаю другие тест-кейсы. По утверждению, я мгновенно вижу, что что-то пошло не так, но все равно не нахожу ошибку. Для поиска ошибки отладка все равно полезна (с красным тестовым кейсом я выполняю проблемные пути кода, с отладчиком я нахожу ошибку).

Если вас интересует тестирование-автоматизация, посмотрите на шедевр xUnit Test patterns .