Здравствуйте, strngr9, Вы писали:
S>сабж в чистом виде используется в реальных больших проектах вообще? или только на учебных стендах?
В каких то — наверняка используется. Мир большой. В большинстве — очень сомневаюсь. Моё имхо — у числа тестов есть некая золотая середина, до которой они приносят большую пользу, а выше которой — польза сильно падает, а вред (в виде возросшего объёма кода для поддержки) начинает расти. И эта золотая середина не позволяет писать весь код с ТДД подходом (т.к. при его правильном применении тестов нужно ну очень много).
Здравствуйте, strngr9, Вы писали:
S>сабж в чистом виде используется в реальных больших проектах вообще? или только на учебных стендах?
В одной конторе я был инициатором такого подхода, СТО поддержал.
Но сейчас мы скатимся во флейм: "Как определять большой проект: по количеству разработчиков или инсталляций, размеру инвестиций или прибыли..."
Здравствуйте, vsb, Вы писали:
vsb>Моё имхо — у числа тестов есть некая золотая середина, до которой они приносят большую пользу, а выше которой — польза сильно падает, а вред (в виде возросшего объёма кода для поддержки) начинает расти. И эта золотая середина не позволяет писать весь код с ТДД подходом (т.к. при его правильном применении тестов нужно ну очень много).
У меня есть теория, которая описывает, где проходит эта золотая середина.
Код отчётливо делится на библиотечный и прикладной. Я не понимаю, почему авторы книжек и прочие философы эту разницу не берут в расчёт, ведь это очень разные животные. Например, высокая связность — это хорошо или плохо? Ну, в прикладном коде, наверно, это не очень хорошо. А в библиотечном? Зачем, например, нужна библиотека для работы с геометрией, если все её функции не принимают на вход свой же Point?
Что касается тестов, они оптимальны, когда продуктовые. Есть продукт, мы его тестируем как таковой. Очевидно, для библиотечного кода продуктовыми тестами будут юнит-тесты, потому что продукт там — сами функции/объекты/интерфейсы. В каком порядке их писать, дело десятое.
Для прикладного же кода, скажем, для формы в приложении, продуктовыми тестами будет что-то другое. Какой-нибудь макрорекордер, или ещё что-нибудь в этом роде.
Здравствуйте, strngr9, Вы писали:
S>сабж в чистом виде используется в реальных больших проектах вообще? или только на учебных стендах?
TDD это религия. Какие бы догматы не были у религии в реальном мире никто никогда их на 100% не соблюдает.
Поэтому весь проект на TDD вы вряд ли встретите в дикой природе.
Здравствуйте, Alekzander, Вы писали:
A>У меня есть теория, которая описывает, где проходит эта золотая середина.
Любая попытка такого деления будет работать на очень ограниченном наборе проектов и всегда найдется такой проект, где тот или иной принцип будет вредить. Первична цель проекта, а затем инструменты для достижения цели. И у каждого инструмента есть свои сильные и слабые стороны, совместимость с другими инструментами. В общем, главное — это гармония
Но такое деление, бесспорно, может быть полезно для начинающих как понятное руководство к действию, не требующая большого опыта за спиной.
vsb>В каких то — наверняка используется. Мир большой. В большинстве — очень сомневаюсь. Моё имхо — у числа тестов есть некая золотая середина, до которой они приносят большую пользу, а выше которой — польза сильно падает, а вред (в виде возросшего объёма кода для поддержки) начинает расти. И эта золотая середина не позволяет писать весь код с ТДД подходом (т.к. при его правильном применении тестов нужно ну очень много).
Дело не в размере проекта, и даже не в числе тестов, а в том, как именно они написаны. Я довольно часто встречал совершенно идиотские юнит-тесты, которые написаны в огромном количестве, очень многословно, и при этом совершенно не по делу, т.к. они тестировали какую-то внутреннюю логику.
Также я встречал превосходные примеры property-based тестов, которые сначала были очень неочевидны, но их было куда проще поддерживать, и количество строк кода в них было вовсе не запредельным.
Иными словами, хорошо написанный софт очень выигрывает от TDD. Его расширение и поддержка. От размера проекта слабо зависит. Более того, маленькие проекты по TDD сделать проще — в больших, обычно, шибко много макарон, и все покрыть тестами заранее не получается.
Здравствуйте, MaximVK, Вы писали:
MVK>Любая попытка такого деления будет работать на очень ограниченном наборе проектов и всегда найдется такой проект, где тот или иной принцип будет вредить.
Например?
Я говорю конкретно про изложенную выше классификацию. Где она не работает? Заранее спасибо за пример.
Здравствуйте, strngr9, Вы писали:
S>сабж в чистом виде используется в реальных больших проектах вообще? или только на учебных стендах?
TDD в чистом не видел никогда,
но видел когда разработка начинается с тестов, потому что прогон функциональности на приложении весьма не прост.
и там сначала пишут в тестах — убеждаются, что все ок, потом катят и смотрят как уже работает в инфраструктуре.
Но это касалось только боевой бизнеслогики, на базе некоторого самодельного фреймворка.
Здравствуйте, SkyDance, Вы писали:
G>>TDD это религия. SD>Я б не сказал. Скорее, это соглашение "сначала формализуй поведение своей программы, потом ее напиши".
Это в оригинале. А в имплементации — это часто очень религия.
Здравствуйте, strngr9, Вы писали:
S>сабж в чистом виде используется в реальных больших проектах вообще? или только на учебных стендах?
Я не участвовал в больших проектах. При этом весь код, который я писал последние 15 лет, так или иначе был покрыт тестами — и тесты писались более-менее параллельно с кодом. Не *перед* кодом, а параллельно. Тесты — это один из моих основных критериев декомпозиции. При этом я считаю что первый шаг "напишите тест и убедитесь, что он не компилируется" — это глупость.
