http://neverworkintheory.org/2016/10/05/test-driven-development.html> Context: Test-driven development (TDD) is an agile practice claimed to improve the quality of a software product, as well as the productivity of its developers. A previous study (i.e., baseline experiment) at the University of Oulu (Finland) compared TDD to a test-last development (TLD) approach through a randomized controlled trial. The results failed to support the claims.Хипстеры с гитхаба опять говна нажрались.
>испытание на студентиках>подразумевается, что студентишки репрезентативная модель, когда реальный коллектив немыслим без специалистов с многолетним опытом коммерческой разработки.Опять говновузики пыжатся показать себя релевантными к чему-либо происходящему в реальном мире.Но я не пытаюсь защищать TDD. Практика довольно специфическая. В теории будет работать, если под нее выстраивать всю парадигму разработки, и будут опять же опытные люди, которые будут направлять и поддерживать. На практике такого не видел, многие хотят модную аджайл приблуду, но менять парадигмы, имея за плечами тонны легаси, желающих значительно меньше. Обычно все скатывается с "а давайте попробуем" к "ну ладно, времени в обрез, давайте щас быстро сделаем задачу, а тесты после напишем". Это точно не "серебряная пуля", которой можно решить проблемы в любом проекте.
Но идея-то неплохая. Студенты в основном на лабах кодят всякие калькуляторы, как раз ниша tdd. Чисто руку набить юнит-тесты писать, чтоб потом меньше возникало "тесты потом напишем"
>>858979> Студенты в основном на лабах кодят всякие калькуляторы, как раз ниша tddДля того, чтобы начинать с тестов нужно до написания кода разобраться с контрактами компонентов, классов, интерфейсов, всего этого. Юнит-тест написанный до реализации компонента будет как раз этот контракт фиксировать. То есть это или действительно какая-то простая и маленькая по объему программная система, которую один человек может полностью охватить от А до Я. Либо проектированием должен заниматься отдельный человек или группа разработчиков, желательно с опытом. Это уже совсем другая песня.
Для студентов и прочих для начала стоит разобраться с построением uml диаграмм, вот уж где основы основ.Профессионалы в виду наличия опыта имеют представление о интерфейсах и о способах их реализации, они без построения uml переходят к разработке типовых задач (через tdd или whatever ), конечно, если внешние и внутренние условия позволяют им это.Отсюда возникает забавный казус о том, что люди, непонимая, что и зачем им нужно, слепо копируют методики и ожидаемо обсираются. В случае с tdd, это означает переписывание интерфейсов и тестов к ним, из-за ошибок при проектировании.Проще говоря, учить tdd это все равно что учить интегральные уранения, не освоив самые основы линейной алгебры. Оно конечно можно, только вот ужасно неэффективно и больно.Вывод из этого прост: нужно поменьше слушать рандомных Васянов, а думать своей головой или головой вашего тим-лида (если повезло найти толкового). Вот к таким вот выводам я пришел.
>>859018>Для студентов и прочих для начала стоит разобраться с построением uml диаграмм, вот уж где основы основ.Двачую.Узнать в начале карьеры, что они нужны только для иллюстрации примеров в книжках и пояснения каких-то концепций на вайтборде - сэкономить много времени и нервов. Потом оказывается, что UML поддерживать ещё хуже, чем комментарии в коде или проектной вики - нельзя просто править текст и закоммитить: нужно вылезать из любимой IDE, открывать visio/RR/whatever, и пушить в репу какие-то бинарные файлы. Да и выбрасывать потом жаль.>Профессионалы в виду наличия опыта имеют представление о интерфейсах и о способах их реализации, они без построения uml переходят к разработке типовых задач (через tdd или whatever ), конечно, если внешние и внутренние условия позволяют им это.Рисование UML делает тебя профессионалом только в глазах студентов и старенького преподавателя программирования в школе. А вот замокать IThirdPartyLibrary тесте, или запустить эту самую либу тест-раннером и посмотреть в дебаге, что она возвращает, прибавляет тебе профессионализма. >Отсюда возникает забавный казус о том, что люди, непонимая, что и зачем им нужно, слепо копируют методики и ожидаемо обсираются. см. UML>В случае с tdd, это означает переписывание интерфейсов и тестов к ним, из-за ошибок при проектировании.F2/Shift+F6/Ctrl+F6 в Idea/VS+Resharper - вот и всё переписывание. И упавшие тесты тебе подскажут, что сломалось. Ошибок проектирования будет гораздо меньше, когда ты в тесте пишешь, как будешь пользоваться каким-то классом, и только после этого реализуешь класс.>Вывод из этого прост: нужно поменьше слушать рандомных Васянов, а думать своей головой или головой вашего тим-лида (если повезло найти толкового). >Вот к таким вот выводам я пришел.Подтверждаю вывод, Васян.
>Рисование UML делает тебя профессионалом только в глазах студентов и старенького преподавателя программирования в школе. А вот замокать IThirdPartyLibrary тесте, или запустить эту самую либу тест-раннером и посмотреть в дебаге, что она возвращает, прибавляет тебе профессионализма. Лет десять назад точно такие же петухи как ты бегали кругоми и хвалили UML картиночки, говорили что генерация кода из UML всех спасет и т.д. и т.п.. История как мы видим не стоит на месте.>>859708>И упавшие тесты тебе подскажут, что сломалось.Так мне и упавшие регрессионные тесты подскажут что сломалось, нахуй TTD нужен? При каждом рефакторе переписывать еще и тесты?
>>859018>разобраться с построением uml диаграммUML какое-то лютое говно, на изучение которого можно потратить время сопоставимое с изучением нового ЯП. Ну и >>859797 все правильно написал, история показала что UML в целом нахуй не нужен. Какие-то отдельные виды диаграмм в нем бывают полезны, но опять же в простейшей форме.> переписывание интерфейсов и тестов к ним, из-за ошибок при проектировании.Это неизбежно, я не видел ни одного крупного проекта, который сразу был бы идеально спроектирован. ИРЛ всегда про что-то могут забыть, не предусмотреть, требования могут поменяться по ходу разработки и т.п.TDD отчасти позволяет с этим бороться, так как кроме своей системы ты сразу пишешь и код который ее использует. И всякие интерфейсные недоработки типа "а вот тут оказывается удобно бы добавить еще вот такой параметр к методу" становятся видны сразу.
>>859909Ты ведь учитываешь, что мы говорим в контексте статьи ОП о том, что > This painstaking study is the latest in a long line to find that test-driven development (TDD) has little or no impact on development time or code quality. ТДД — это не такая простая штука, методике нужно учится. Нельзя сесть и получить +n% к качеству кода и скорости разработки, если нет совсем нет опыта. И студенты это показали.Но если tdd начинается с с построения интерфейсов для тестируемого кода, то почему не начать с простого: с изучения как эти интерфейсы строить. Вот и весь тезис. Заодно можно узнать, что, оказывается, есть не только tdd, но и mdd + uml. И это таки полезные штуки, особенно когда нужно визуализировать паттерн. Но перебарщивать не нужно, да. Впрочем как и всегда.
>>859991>ТДД — это не такая простая штука, методике нужно учитсяTDD как раз очень простая штука, которую можно на простом примере объяснить за одну лекцию, что нам в универе и сделали.Но вот понять в чем суть тестирования вообще и тдд в частности, понять это всей своей сущностью, а не чисто формально какие-то тестики нахуярить - это да, это опыт нужен.Как там кто-то говорил "тесты это как оливки, в детстве их все терпеть не могут, а вот как взрослеют - начинают их любить".
