Что лучший аргумент должен убедить разработчиков изучать TDD?
В деятельности onDestroy() сделать:
@Override
protected void onDestroy() {
super.onDestroy();
webView.destroy();
}
11 ответов
TDD - это компромисс типа «заплати мне сейчас или заплати позже». Если вы подсчитываете только время от начала кодирования до проверки кода, то TDD часто занимает больше времени, особенно при первом изучении TDD. Окупаемость приходит позже, на этапе тестирования, а также в будущих раундах кодирования.
На этапе тестирования я обнаружил, что с TDD:
- у меня было значительно меньше ошибок. Мой последний код TDD. У меня были ошибки только из-за непонимания требований (или изменений) или в тех областях, где я не мог протестировать код (в данном случае код PHP).
- Ошибки, которые у меня были, были в целом проще для воспроизведения во время тестирования, потому что я уже получил тестируемую систему.
- Исправление ошибок было быстрее, и с тестами я мог быть увереннее, что я не вводил новые ошибки.
Сам код обладал следующими свойствами:
Когда я начинал думать как клиент кода, код, как правило, было проще в использовании. (Это одно из преимуществ написания тестов в первую очередь.)
Код легче тестировать.
Написание модульных тестов проще (и во многих случаях веселее) непосредственно до, а не после, поэтому пишется больше тестов .
Код легче реорганизовать и очистить. Это было особенно верно для Python, где инструментам автоматического рефакторинга сложнее.
Из-за этого, когда пришло время пересмотреть код, его было легче понять и легче изменить, плюс у нас были по крайней мере некоторые регрессионные тесты уже на месте.
Это означает, что срок окупаемости TDD может быть на месяцев позже. Кроме того, особенно сложно запустить TDD с устаревшим кодом. Затем нужно время, чтобы научиться писать хорошие тесты (плохой набор тестов может быть либо недостаточным, либо, что еще хуже, быть хрупким, что усложняет, а не упрощает рефакторинг), и как провести тестирование сложной системы.
Я должен признать, что мне не удалось убедить слишком много людей перейти на TDD. Думаю, я перешел в основном потому, что хотел более простой способ тестирования, а также имел возможность узнать, как это сделать, с небольшой базой кода и личным проектом.
Разных людей убедят (или нет) по-разному, поэтому единственный честный ответ - «это зависит от обстоятельств».
Один из способов, который я видел несколько раз, - это сидеть с кто-то после того, как они боролись с куском кода, и воссоздайте его с помощью TDD. Результирующий код обычно меньше и яснее.
Никакие аргументы не убедят кого-либо использовать TDD.
Вы должны ПОКАЗАТЬ их и продемонстрировать преимущества. Легче заставить кого-то «загореться», показывая, а не рассказывая.
Возможно, они знают лучше.
Модульное тестирование разработчиками - чрезвычайно полезная практика, и я не могу переоценить ее преимущества не только во время начальной разработки, но и во время рефакторинга, когда модульные тесты могут своевременно выявлять не только обычные дефекты кода, но и отклонения от предположений, сделанных разработчиками, которые никогда не были зафиксированы в официальной документации и, следовательно, вероятно, утрачиваются во время рефакторинга.
При этом TDD - это не волшебная пыльца пикси:
- подход «просто напишите достаточно кода, чтобы пройти тест» дает ложные срабатывания. Часто существуют известные заблуждения и проблемы, которые не может решить подход «достаточно». На ум приходят ошибки распределенных систем или проблемы производительности NUMA. Простое воплощение этих требований в простом выражении этих тестовых примеров для TDD само по себе превратилось бы в полноценную работу.
- Бурный рост moqs выходит из-под контроля для любого серьезного проекта. mocks - это код, как и любой другой код, их нужно поддерживать и просто не писать на ровном месте.
- TDD часто используется как предлог для исключения тестирования QA. «Наш разработчик уже написал проверенный идентификатор, давайте отправим его» полностью игнорирует сквозное функционально-ориентированное тестирование, которое QA должно охватывать
- Я не доверяю лисе, охраняющей курятник. неправильный алгоритм может успешно пройти TDD, если одни и те же ошибки будут допущены как в тесте, так и в реализации.
- Все методологии в конечном итоге пытаются использовать процесс для замены таланта.
Моя основная проблема с TDD заключается в том, что она представлена как волшебное решение большинства проблем разработки, но его сторонники скрывают его стоимость. Удвоение или утроение базы кода с помощью moqs не бесплатно. Я бы предпочел увидеть несколько всеобъемлющих модульных тестов, написанных во время разработки. Подход TDD «сначала тестирование», я еще не видел его преимуществ в проекте реального размера.
Я понимаю, что меня сейчас забьют до смерти за то, что я опубликовал это, но какого черта, кого это волнует ...
Перечисленные вами аргументы не являются рациональными, логическими аргументами. У них нет аргументов (если вы на самом деле просто не суммировали гораздо более длинные реальные аргументы.)
Таким образом, я не думаю, что вы сможете убедить любого, кто делает эти утверждения, собственными рациональными аргументами. Лучшим способом будет обратиться к источнику их аргументов; опыт. Либо заставьте их временно использовать TDD, чтобы посмотреть, что они думают о нем, либо сами сделайте TDD работу, которая явно очень хорошая работа, и представьте ее в качестве примера.
(Я не сторонник TDD. Это практический способ убедить меня, что это хорошая идея.)
Как профессиональный разработчик более 10 лет, лучший аргумент, который я могу выдвинуть, - это то, что даже я обнаружил свои ошибки до того, как я действительно смог «запустить» приложение.
Я также обнаружил, что дизайн моего кода был более надежным и его легче было изменить, и это придало мне больше уверенности в рефакторинге.
«Довольно успешный» не означает «действительно успешный».
Другой Большое преимущество состоит в том, что мне больше не нужно писать тестовые программы, поскольку бегуны модульных тестов фактически становятся моей тестовой системой.
Я не практикую TDD. Хотя я понимаю, насколько это хорошо, если у вас есть сложные проекты, в которых нужно протестировать множество различных тестовых примеров, я не вижу большой пользы в использовании этого, скажем, в простом веб-приложении.
Один из способов, которым кто-то может убедить меня использовать TDD можно было бы, если бы мы взяли один и тот же проект и выполняли его бок о бок, чтобы посмотреть, кто получит лучшие результаты, а кто быстрее выполнит задачу.
Моментом "ага" для меня было чтение главы 2 книги Джеймса Ньюкирка "Разработка через тестирование в Microsoft.Net". (Не то чтобы остальная часть книги не имела большого значения ... он посвящает несколько глав построению многоуровневого приложения в TDD.)
Он создает простой стек, но вы можете увидеть, как код "эволюционирует" его сложность вместо того, чтобы начинать сложным.
Даже в этом случае вам все равно будет сложно убедить тех, кто возражает против, потому что, похоже, TDD требует гораздо больше работы, чем традиционное программирование. Однако большинство разработчиков анти-TDD забывают учитывать время разработки модульных тестов в конце, по крайней мере, по моему опыту.
Сопряжение с ними. Необязательно называть это «парным программированием» - это страшно для тех, кто не хочет даже рассматривать «радикальные» методы, такие как TDD, - но если вы двое сидите за столом и вместе работаете над одной и той же проблемой, легко решить эту проблему. продемонстрировать ценность TDD. Это не может быть концом разговора, но это чертовски хорошее начало. Придает доверие к остальной части разговора и дает что-то реальное в качестве основы для дальнейшего обсуждения.
Show them this presentation. It sold me.
http://www.slideshare.net/sebastian_bergmann/testing-with-phpunit-and-selenium-156187
Any programmer who's ever been faced with a really complex task with a lot of edge conditions should be able to see the value of TDD. When it comes to something like making sure a search engine will match certain strings, TDD is the only way you'll be able to stay sane during maintenance -- the only way to be sure you've fixed one case without breaking a few others is with automated testing.
Тщательные модульные тесты уменьшают количество ошибок, но они также уменьшают рецидивирование или масштаб ущерба, вызванного рецидивированием.