T>>А не мог ли бы ты описать примерную твою предметную область и типичные сроки сдачи чего-либо?
E>Эта информация бесполезна без информации о масштабе зарплаты по отношению к среднему уровню в данной предметной области в данном регионе.
Нененене. Это уже многое прояснит.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>А не мог ли бы ты описать примерную твою предметную область и типичные сроки сдачи чего-либо? G>Последнее чем занимался — веб приложения, в основном электронная коммерция, документооборот и все такое. Итерации короткие, неделя-две.
Понятно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Константин Б., Вы писали:
КБ>>>Потому что в TDD заниматься проектированием запрещено, поэтому разбить подсистему на компоненты можно, только если этого потребуют тесты. А как вы будете писать тесты для компонент, если компоненты у вас еще не выделены.
SD>>Вернитесь на землю — написанием тестов на систему в целом TDD не занимается. тесты на новые микрокомпоненты пишутся глядя на проект новых компонент. а он в свою очередь взялся из нового use case. Те проектировать и вообще думать не запрещено
КБ>Ну не совсем. Последовательность примерно такая. Use case на подсистему -> тест на подсистему -> use case на компонент -> тест на компонент.
КБ>Написать тест на компонент, до теста на подсистему в рамках TDD не получается.
Как бы это объяснить. use case на систему. без всяких "под". да qa люди сразу планируют тест на систему для этого use case, но он не наш — не unit. И соответственно конфликта нет, как нет долговисящего красного uber теста.
А программисты используют свои маленькие тесты в своих целях. Как говорил человек, у которого я многому старался научиться, тесты нужны чтобы успеть вовремя. То есть они не цель, а средство достижения цели. Удачи!
Здравствуйте, Константин Б., Вы писали:
КБ>Потому что это будет не TDD. В TDD код пишется только тогда, когда его необходимость покажут тесты. Т.е. пока тесты для подсистем не покажут необходимость маленьких компонент — маленьких компонент не будет.
А они покажут, ты не переживай. Написать unit test для класса в несколько килострок кода — задача весьма нетривиальная и противная, поэтому его захочется разбить на классы помельче уже на этом этапе. И это хорошо, т.к. написать тот же тест после того, как будет написан этот самый "класс в несколько килострок" — эта задача может перейти вообще в разряд "mission imposible".
Опа, а что это такая благодарная тема и до сих пор не в КСВ?%)
Что-то никто не пишет о ассертах/встроенных проверках. По теме: зависит от проекта. Допустим в воспомогательных фреймворках (ака костыли) мегарулят контракты (самописные, ждём fw 4). Естественно, они ни разу не отменяют юнит-тестов, но привычка явно проверять принимаемые аргументы/проверять состояние в сложных алгоритмах нехило снижает уровень ошибок.
Используется примерно так (специально нашёл метод с избыточными проверками):
public static string ChangeExtension(string tokenValue, string newExtension)
{
Code.NotNull(newExtension, "newExtension");
Code.GreaterThanOrEqual(tokenValue.Length, "tokenValue.Length", 2);
Code.AssertArgument(
ContainsOnlyValidChars(newExtension), "newExtension",
@"Extension should not contain any of invalid chars.");
Code.AssertArgument(
newExtension.LastIndexOf(Dot) == 0, "newExtension",
@"Extension should starts with dot char ('.') and should not contain dots at any another position.");
return GetNameWithoutExtension(tokenValue) + newExtension;
}
В качестве бонуса получается централизованно обрабатывать нарушение утверждений (допустим делать Debugger.Break() перед throw/трейсить etc).
Ну а если есть регулярные интеграционные тесты + code review после каждого изменения, то юнит-тесты занимаются именно тем, чем и должны — отловом косяков в нетривиальном коде.
public static string ChangeExtension(string tokenValue, string newExtension)
{
Code.NotNull(newExtension, "newExtension");
Code.GreaterThanOrEqual(newExtension.Length, "newExtension.Length", 2);
Code.AssertArgument(
ContainsOnlyValidChars(newExtension), "newExtension",
@"Extension should not contain any of invalid chars.");
Code.AssertArgument(
newExtension.LastIndexOf(Dot) == 0, "newExtension",
@"Extension should starts with dot char ('.') and should not contain dots at any another position.");
return GetNameWithoutExtension(tokenValue) + newExtension;
}
Это кстати к вопросу о покрытии тестами юнит-тестов
Увы. Некоторые участники все еще in business. Могут обидеться. С другой стороны, в честь пятницы, могу рассказать сказку, по мотивам. Предметраня область изменена, действующие лица заретушированны. Все равно такое могло произойти с кем угодно.
Сказ о смертельном баге
Жила-была одна контора, которая делала, скажем движки для веб-почты. Но сама их не особенно использовала, а продавала кому понадобятся. И вот подошел к ней как-то на ярмарке один стартап и говорит:
–- Хочу движок почтовый, да не простой, а кастомный.
-- Любой каприз за ваши деньги, -- отвечает контора.
Тот продолжает:
-- Простых движков ко всему интернету натыкано, как репьев в огороде. А мы хотим веб-почту для публичных людей организовать. Певцов, политиков, актеров, ну вы поняли. Им столько почты приходит, что они ей пользоваться уже не могут.
Мы, говорит, тут уже все продумали. И как начнет требования перечислять, только знай, записывай. И под нагрузкой сервер падать не должен, а нагрузка немалая, а в пике и того больше. И отдельный интерфейс нужен для специально обученной девочки-секретаря. И свистелки-дуделки разнообразные. А главное, попросил он фичу-мегафичу. Еще не придумал какую. Ну например, чтоб одинаковые письма в кучи группировались. А что, полезно. Скажем, напечатает таблоид о помолвке 15 летней певички с 50-летним бизнесменом, так половина почты про это. Согласовали они тербования со сроками, да спустили задачу программистам. Ну а те, не долго думая требуемое и выпилили. А в качестве фичи-мегафичи прикрутили... ну скажем Байесовский классификатор.
Стартап на получившийсв движок посмотрел, интерфейс пощупал, в дуделки подудел да и остался доволен. И начал он свой проект раскручивать, а особенно упирал на эту уникальную фичу, которой ни у кого больше нет. Действительно, тем у кого меньше 100 писем в день и без нее жить легко. А прочие или сами фильры настраивают, или секретаря держат. Вот только в фиче-менафиче оказалась бага-мегабага. То важное письмо с предложением зарубежных гастролей среди фанспама спрячет. То плохие стихи в важное пропихнет. В общем, как-то не вкатила эта фича пользователям. Другие свистелки-дуделки не особенно интересны были. Gmail тоже от нагрузки не падает, свистелками не обделен, да и интерфейс имеет понятный среднему барабанщику. Зато за него платить не нужно. В общем, через полгода стартап закрылся. А еще через полгода при ревью кода по поводу фикса очередного бага кто-то обнаружил в что мегафича никогда и не работала нормально. И ошибка-то была банальная: то ли плюс, вместо минуса, то ли не на тот коэффициент умножили при нормировке. А что приемочные тесты проходили, так они синтетические и не особо тщательные.
Может, конечно, сказать, что не в баге дело, просто идея не пошла. Ну так на то это и сказка.
Здравствуйте, Sinix, Вы писали:
S>Что-то никто не пишет о ассертах/встроенных проверках. По теме: зависит от проекта. Допустим в воспомогательных фреймворках (ака костыли) мегарулят контракты (самописные, ждём fw 4). Естественно, они ни разу не отменяют юнит-тестов, но привычка явно проверять принимаемые аргументы/проверять состояние в сложных алгоритмах нехило снижает уровень ошибок.
Здравствуйте, BokiyIS, Вы писали:
BIS>Привет всем.
BIS>P.s. быстро прошелся поиском, вроде похожей темы небыло. В любом случае освежить не помешает
Еще интереснее увидеть где-то структуру кода и сам исходный код РЕАЛЬНЫХ лучше коммерческих проектов где юнит тесты используються.
Здравствуйте, assad, Вы писали:
A>Здравствуйте, BokiyIS, Вы писали:
BIS>>Привет всем.
BIS>>P.s. быстро прошелся поиском, вроде похожей темы небыло. В любом случае освежить не помешает A>Еще интереснее увидеть где-то структуру кода и сам исходный код РЕАЛЬНЫХ лучше коммерческих проектов где юнит тесты используються.
Django покатит? Оупенсорс правда(под коммерческим подразумевается закрытый или приносящий деньги?). Вот пример (доктесты вроде как тоже под юниттесты катят). Coverage пока вроде 54.4%, но растёт.
Здравствуйте, Пацак, Вы писали:
П>Здравствуйте, Константин Б., Вы писали:
КБ>>Потому что это будет не TDD. В TDD код пишется только тогда, когда его необходимость покажут тесты. Т.е. пока тесты для подсистем не покажут необходимость маленьких компонент — маленьких компонент не будет.
П>А они покажут, ты не переживай. Написать unit test для класса в несколько килострок кода — задача весьма нетривиальная и противная, поэтому его захочется разбить на классы помельче уже на этом этапе. И это хорошо, т.к. написать тот же тест после того, как будет написан этот самый "класс в несколько килострок" — эта задача может перейти вообще в разряд "mission imposible".
Мы все еще про TDD? Откуда при TDD взялся класс на несколько килострок без юнит-теста?
Здравствуйте, Константин Б., Вы писали:
КБ>Мы все еще про TDD?
Да
КБ>Откуда при TDD взялся класс на несколько килострок без юнит-теста?
А класса как такового еще нет, есть функционал, для которого надо написать код в несколько килострок. При обычном подходе есть далеко не нулевая вероятность, что кодер Вася впихнет этот код в один класс (поленится, поторопится к срокам или он просто потомственный раздолбай), добьется видимой работоспособности, закоммитит и забудет, а разгребать эту помойку придется кодеру Пете где-нибудь через полгода, когда всплывет какой-нибудь баг в использующих её модулях или понадобится чуть-чуть изменить её поведение. При TDD же Васе с самого начала придется самому трахаться с тестами для этого кода, а следовательно: а) заранее думывать о том, как он будет использоваться "снаружи" и б) лично наблюдать все чередования красный-зеленый-красный, которые возникают в уже написанных им тестах при каждой его модификации. Соответственно, мысль "а не разбить ли это безобразие на что-нибудь попроще", по идее, должна его рано или поздно все-таки посетить.
Да у нас просто практика такая — крайне осторожно относиться к компонентам "не из коробки". Как правило один-два милых косяка вылазят. Например, memory leak у datetimepicker'a был. Ещё были ньюансы с unity к vs 2005 (2-я entlib, весенний какой-то месяц). Ещё (хронически) crystal reports. Так что нафиг-нафиг хвататься за модную штуку при наличии самописного и работающего в силу своей примитивности. И без того хватает косяков у штатных велосипедов.
Самое печальное — это покупные контролы. Снаружи конфетка, а как заглянешь рефлектором...
Pex кстати щупал. Занятная штука. Может даже поиспользуем как подвернётся возможность.
BIS>Привет всем. BIS>Хотел узнать, применяете ли вы в рабочих проектах модульное тестирование (а возможно и вообще TDD) BIS>и какие мысли у вас есть на этот счет. Стоит ли игра свеч или нет?
В чистом виде — не применяю, т.к. система сложная и писать тест — всё равно, что пятикратно переписать саму систему.
TDD применимо к маленьким, чётко оговоренным библиотечкам — синус посчитать, выходные дни... Для любой мало-мальски сложной системы тестирующие модули — болото, засасывающее человекочасы и всё равно не дающее никакой гарантии качества.
Некие простенькие тесты нужны, но исключительно убедиться, что после изменений не сломались обычные операции.
? J>Вопрос не праздный — давно интересно как это делают умные люди ...
имхо никак — тк юнит-тест не может воспроизводить все возможные комбинации при работе потоков.
те. тест может проверять переходы-состояния для каждого из параллельных, но не вместе.
Здравствуйте, matumba, Вы писали:
BIS>>Привет всем. BIS>>Хотел узнать, применяете ли вы в рабочих проектах модульное тестирование (а возможно и вообще TDD) BIS>>и какие мысли у вас есть на этот счет. Стоит ли игра свеч или нет?
M>В чистом виде — не применяю, т.к. система сложная и писать тест — всё равно, что пятикратно переписать саму систему.
M>TDD применимо к маленьким, чётко оговоренным библиотечкам — синус посчитать, выходные дни... Для любой мало-мальски сложной системы тестирующие модули — болото, засасывающее человекочасы и всё равно не дающее никакой гарантии качества. M>Некие простенькие тесты нужны, но исключительно убедиться, что после изменений не сломались обычные операции.
Открою тайну: нормальные сложные системы состоят из "маленьких, чётко оговоренных библиотечек".
А если это не так (т.е. код не разделен на "маленькие, чётко оговоренные библиотечки", потому что все от всего зависит), то это называется простым словом "спагетти".
Здравствуйте, jazzer, Вы писали:
M>>TDD применимо к маленьким, чётко оговоренным библиотечкам
J>Открою тайну: нормальные сложные системы состоят из "маленьких, чётко оговоренных библиотечек".
Jazzer, у меня тоже есть для вас сюрприз! "маленькие, чётко оговоренные библиотечки" — это СТРОИТЕЛЬНЫЕ БЛОКИ, ничего не значащие сами по себе. Будучи же собранные в систему, они и составляют ту сложную хренотень, которую не так просто протестировать! Более того, метафора "кирпичей" хороша только в статьях — на деле, взаимодействие и проникновение кода куда сложнее. Если модуль А делает работу, Б её обновляет, при этом модуль В синхронно работает с А и Б, обрабатывая результаты обоих, я бы не стал на вашем месте бросаться это тестировать "юнит-тестами" — рискуете поседеть и всё равно ни черта не решить.
Увлечение новым buzzword "TDD" — это ещё один манёвр известного "огонь и движение".
Здравствуйте, matumba, Вы писали:
M>Здравствуйте, jazzer, Вы писали:
M>>>TDD применимо к маленьким, чётко оговоренным библиотечкам
J>>Открою тайну: нормальные сложные системы состоят из "маленьких, чётко оговоренных библиотечек".
M>Jazzer, у меня тоже есть для вас сюрприз! "маленькие, чётко оговоренные библиотечки" — это СТРОИТЕЛЬНЫЕ БЛОКИ, ничего не значащие сами по себе. Будучи же собранные в систему, они и составляют ту сложную хренотень, которую не так просто протестировать!
Неправда. Каждый кирпичик тестируется отдельно, особенно внимание уделяется тому как он обращается к другим кирпичикам (моки, контракты). А потом работает транзитивность:
Если A корректно работает и корректно вызывает B и B корректно работает и корректно вызывает C, то композиция A->B->C.
Правда тут есть одно НО: когда мы пишем тесты, то не можем покрыть всех вариантов, поэтому композиция в некоторых случаях может не работать.
Но с помощью интеграционных тестов вполне можно проверить что некоторая композиция работает корректно на наиболее вероятных входных данных.
M>Более того, метафора "кирпичей" хороша только в статьях — на деле, взаимодействие и проникновение кода куда сложнее.
Это зачастую признак хренового кода.
M>Если модуль А делает работу, Б её обновляет, при этом модуль В синхронно работает с А и Б, обрабатывая результаты обоих, я бы не стал на вашем месте бросаться это тестировать "юнит-тестами" — рискуете поседеть и всё равно ни черта не решить.
Такие случаи находятся за пределами компетенции юнит-тестов.
Если у вас есть состяние гонки, то его вообще очень сложно отловить тестами.
M>Увлечение новым buzzword "TDD" — это ещё один манёвр известного "огонь и движение".
TDD, это не тесты, TDD — методика дизайна кода, причем вполне хорошо работающая при детальном дизайне.
