Что вы думаете о вездесущем "Test, Test, Test!" принцип?

Question

В старые времена программирование использовало меньше догадок. Я написал бы несколько строк кода и был бы на 100% уверен в том, что код делает, а что нет, с первого взгляда. Ошибки были в основном опечатками, но не в функциональности.

В последние годы, как мне кажется, была тенденция к программированию методом проб и ошибок: написать код (как в черновике), а затем выполнять итерационную отладку, пока поведение программы не будет соответствовать требованиям. Тестируйте и тестируйте снова, а затем снова. Забавно то, что в моей Visual Studio кнопка «Выполнить» была заменена кнопкой с надписью «Отладка» (= Я знаю, что у вас есть ошибки!). Я должен признать, что в нескольких приложениях, которые я пишу, я не могу гарантировать безошибочный код.

Что ты думаешь? Или, может быть, наши системы сейчас слишком сложны (совместимость браузера / ОС / пакета обновления и т. Д. И т. Д.), И это оправдывает тестирование во всех типах сред.

Answer 1

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

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

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

Answer 2

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

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

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

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

Answer 3

Ответ одним словом - «Сложность». Реальный ответ - «Ненужная сложность»! Принципы бухгалтерского учета не изменились за последние 30 лет. Почему тогда написание системы бухгалтерского учета сегодня намного сложнее? Хорошо иметь графический интерфейс пользователя, но нужно ли идти за борт?

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

Когда мы отдаем предпочтение форме, а не функции, мы должны заплатить цену.

Answer 4

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

Answer 5

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

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

Answer 6

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

Answer 7

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

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

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

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

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

Если вы заинтересованы в автоматизации тестирования, взгляните на шедевр xUnit Тестовые шаблоны .

Answer 8

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

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

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

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

Answer 9

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

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