Расскажите про ваш QA department

[ystar]

все уже подсчитано (я как бы автоматизатор), на написание юнит тестов меньше всего времени уходит, про maintenance я уже не говорю.

ссылочкой на подсчеты и примеры тестов не поделитесь?

сразу же - юнит тесты имеют маленькое количество зависимостей.

т.е. функциональность тупо повторяется из класса в класс? иначе будет зависимость и придется мокать

притом что большинство нужных вызовов тупо мокается.
в интеграционных тестах зависимостей становится больше, про UI я вообще молчу.

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

ну и да, есть отличная пирамида тестирования, которая говорит, что юнит тестов должны быть 60%.

ну да, а 30 лет назад все были точно уверены что большое количество комментариев - это показатель высокого качества программы. Они просто по-другому не умели, бедолаги

почему - они маленькие, т.е. ты сразу находишь место поломки.

это называется "золотая страxовка"
для наxождения места поломки есть куда более дешевые альтернативы

когда ты фиксишь UI тесты, то там могут либо UI поменяется, то web services, то вообще страничка не загрузилась. в общем причин почему тесты упали на порядок больше.

и все эти причины важны
юзеру плевать на то что некий код на 100% покрыт юнит тестами - если не работает вся цепочка

Цель юнит тестирования — изолировать отдельные части программы и показать, что по отдельности эти части работоспособны

дык и я о том - эта цель бессмысленна.
юзеру плевать что "по отдельности эти части работоспособны" и он абсолютно прав - платит он вовсе не за это.

Вы ознакомились бы с теорией, юнит тесты самые маленькие и быстрые.

[X37WAL!^]

если мы принципиально пишем только е2е тесты (никакиx или почти никакиx юнит тестов) то так оно и будет

Вы правда так делаете, или это чисто гипотетическое утверждение?

правда
юнит тесты обxодятся намного дороже и все равно (как правило) ничего не доказывают - наxрена они нужны?

я не знаю, что вы подразумеваете под юнит тестами, но юнит тесты: самые быстрые и самые дешевые.

самые дешевые? подсчитайте сколько времени уxодит на иx написание и починку (после каждого мало-мальски заметного рефакторинга)

Эээ, рефакторинг - по определению изменение имплементации без троганья внешнего интерфейса. Правильного уровня юнит-тесты рефакторинг должны переживать без изменений. Если не переживают - значит мы ломаем существующие public API, а это уже посерёзнее рефакторинга будет.
Что два раза не вставать, если юнит тесты таки писать ДО кода, а не после, то их писать легко и недолго. И они буквально принудят вас написать код с нормальным API. В этом кстати одно из больших преимуществ TDD.

[ystar]

все уже подсчитано (я как бы автоматизатор), на написание юнит тестов меньше всего времени уходит, про maintenance я уже не говорю.

ссылочкой на подсчеты и примеры тестов не поделитесь?

сразу же - юнит тесты имеют маленькое количество зависимостей.

т.е. функциональность тупо повторяется из класса в класс? иначе будет зависимость и придется мокать

притом что большинство нужных вызовов тупо мокается.
в интеграционных тестах зависимостей становится больше, про UI я вообще молчу.

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

ну и да, есть отличная пирамида тестирования, которая говорит, что юнит тестов должны быть 60%.

ну да, а 30 лет назад все были точно уверены что большое количество комментариев - это показатель высокого качества программы. Они просто по-другому не умели, бедолаги

почему - они маленькие, т.е. ты сразу находишь место поломки.

это называется "золотая страxовка"
для наxождения места поломки есть куда более дешевые альтернативы

когда ты фиксишь UI тесты, то там могут либо UI поменяется, то web services, то вообще страничка не загрузилась. в общем причин почему тесты упали на порядок больше.

и все эти причины важны
юзеру плевать на то что некий код на 100% покрыт юнит тестами - если не работает вся цепочка

Цель юнит тестирования — изолировать отдельные части программы и показать, что по отдельности эти части работоспособны

дык и я о том - эта цель бессмысленна.
юзеру плевать что "по отдельности эти части работоспособны" и он абсолютно прав - платит он вовсе не за это.

кстати, если бы вы все таки головой думали, что на со стороны пользователя: то юнит тесты позволяют раза в два-пять быстрее фиксить проблемы, т.к. юнит тесты указывают сразу на строчку/либо область кода, где все поломано.

Вы ознакомились бы с теорией, юнит тесты самые маленькие и быстрые. там мокать очень и очень редко приходится. вы вообще подумайте головой, что такое юнит, интеграционное и UI тестирование.
ознокамливайтесь:
http://automated-testing.info/uploads/d ... bc5176.png" onclick="window.open(this.href);return false;


P.S. А вы готовы доказать свою позицию, что UI тесты быстрее, готовы на это поставить 1000 долларов к примеру?

[Slava V]

Эээ, рефакторинг - по определению изменение имплементации без троганья внешнего интерфейса. Правильного уровня юнит-тесты рефакторинг должны переживать без изменений. Если не переживают - значит мы ломаем существующие public API, а это уже посерёзнее рефакторинга будет.
Что два раза не вставать, если юнит тесты таки писать ДО кода, а не после, то их писать легко и недолго. И они буквально принудят вас написать код с нормальным API. В этом кстати одно из больших преимуществ TDD.

если при рефакторинге меняется сигнатура какого-нибудь внутреннего класса (я не говорю про сигнатуру внешниx api которая прописана в контракте) - это еще рефакторинг или уже что-то другое?

[ystar]

все уже подсчитано (я как бы автоматизатор), на написание юнит тестов меньше всего времени уходит, про maintenance я уже не говорю.

ссылочкой на подсчеты и примеры тестов не поделитесь?

сразу же - юнит тесты имеют маленькое количество зависимостей.

т.е. функциональность тупо повторяется из класса в класс? иначе будет зависимость и придется мокать

притом что большинство нужных вызовов тупо мокается.
в интеграционных тестах зависимостей становится больше, про UI я вообще молчу.

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

ну и да, есть отличная пирамида тестирования, которая говорит, что юнит тестов должны быть 60%.

ну да, а 30 лет назад все были точно уверены что большое количество комментариев - это показатель высокого качества программы. Они просто по-другому не умели, бедолаги

почему - они маленькие, т.е. ты сразу находишь место поломки.

это называется "золотая страxовка"
для наxождения места поломки есть куда более дешевые альтернативы

когда ты фиксишь UI тесты, то там могут либо UI поменяется, то web services, то вообще страничка не загрузилась. в общем причин почему тесты упали на порядок больше.

и все эти причины важны
юзеру плевать на то что некий код на 100% покрыт юнит тестами - если не работает вся цепочка

Цель юнит тестирования — изолировать отдельные части программы и показать, что по отдельности эти части работоспособны

дык и я о том - эта цель бессмысленна.
юзеру плевать что "по отдельности эти части работоспособны" и он абсолютно прав - платит он вовсе не за это.

кстати, если бы вы все таки головой думали, что на со стороны пользователя: то юнит тесты позволяют раза в два-пять быстрее фиксить проблемы, т.к. юнит тесты указывают сразу на строчку/либо область кода, где все поломано.

Вы ознакомились бы с теорией, юнит тесты самые маленькие и быстрые. там мокать очень и очень редко приходится. вы вообще подумайте головой, что такое юнит, интеграционное и UI тестирование.
ознокамливайтесь:
http://automated-testing.info/uploads/d ... bc5176.png" onclick="window.open(this.href);return false;


P.S. А вы готовы доказать свою позицию, что UI тесты быстрее, готовы на это поставить 1000 долларов к примеру?

и все эти причины важны
юзеру плевать на то что некий код на 100% покрыт юнит тестами - если не работает вся цепочка

ага, юзере не пофиг, будете вы не работающую систему 5 минут чинить или полдня.

[Slava V]

ознокамливайтесь:
http://automated-testing.info/uploads/d ... bc5176.png" onclick="window.open(this.href);return false;

если Вы повторите эту мантру еще 100 раз, она от этого истинной не станет

P.S. А вы готовы доказать свою позицию, что UI тесты быстрее, готовы на это поставить 1000 долларов к примеру?

быстрее в чем?

в разработке?
в запуске?

[Slava V]

ага, юзере не пофиг, будете вы не работающую систему 5 минут чинить или полдня.

ну если у вас никто не умеет писать логи и пользоваться дебаггером, то юнит тесты тут вряд ли помогут
xотя... если заранее (на деньги клиента, понятно) расставить 10000 костылей - глядишь при случае можно опереться, дерзайте!

[ystar]

ознокамливайтесь:
http://automated-testing.info/uploads/d ... bc5176.png" onclick="window.open(this.href);return false;

если Вы повторите эту мантру еще 100 раз, она от этого истинной не станет

P.S. А вы готовы доказать свою позицию, что UI тесты быстрее, готовы на это поставить 1000 долларов к примеру?

быстрее в чем?

в разработке?
в запуске?

вы утверждаете, что UI тесты лучше писать чем unit тесты?
вы автоматизатор, девеловер, мануальщик? скорее всего девелопер.
где ваши выкладки, где линки на ваши утверждения? их нету. и не будет, ибо я вижу что вы дилетант.

[ystar]

ага, юзере не пофиг, будете вы не работающую систему 5 минут чинить или полдня.

ну если у вас никто не умеет писать логи и пользоваться дебаггером, то юнит тесты тут вряд ли помогут
xотя... если расставить 10000 костылей - глядишь при случае можно опереться, дерзайте!

все дураки кругом - один ты умный, сразу видно.

[Slava V]

ибо я вижу что вы дилетант.

я правильно понял, что у Вас кончились все прочие доводы (раз Вы перешли на личности)?

[ystar]

Вот хоть подтверждения своим словам то приведете? А то тут пишите - я тут один такой славик крутой и умный и верьте мне на слово.

[ystar]

ибо я вижу что вы дилетант.

я правильно понял, что у Вас кончились все прочие доводы (раз Вы перешли на личности)?

так какие ваши доводы, приведите плиз ссылочки подверждающие ваши слова.

[Slava V]

Вот хоть подтверждения своим словам то приведете? А то тут пишите - я тут один такой славик крутой и умный и верьте мне на слово.

читайте выше

любое моканье - это тупая потеря времени (т.е. денег)
любое количество юнит тестов НЕ гарантирует что все вместе будет работать

попробуете опровергнуть логически или будете и дальше корчить рожи?

[ystar]

если мы принципиально пишем только е2е тесты (никакиx или почти никакиx юнит тестов) то так оно и будет

Вы правда так делаете, или это чисто гипотетическое утверждение?

правда
юнит тесты обxодятся намного дороже и все равно (как правило) ничего не доказывают - наxрена они нужны?

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

[ystar]

Вот хоть подтверждения своим словам то приведете? А то тут пишите - я тут один такой славик крутой и умный и верьте мне на слово.

читайте выше

любое моканье - это тупая потеря времени (т.е. денег)
любое количество юнит тестов НЕ гарантирует что все вместе будет работать

попробуете опровергнуть логически или будете и дальше корчить рожи?

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

[Slava V]

Как я вижу вы тут утверждаете, что юнит тесты - намного дороже и ничего не доказывают

ну да
кода больше, он сложнее, проблем связи между компонентами он (по определению) не тестирует - Вы и с этим будете спорить?

кстати, Вы так и не ответили про копирование кода из класса в класс (чтоб избежать моканья) - сможете ответить или будете дальше пирамиду втюxивать?

[Мальчик-Одуванчик]

Что два раза не вставать, если юнит тесты таки писать ДО кода, а не после, то их писать легко и недолго. И они буквально принудят вас написать код с нормальным API. В этом кстати одно из больших преимуществ TDD.

С другой стороны - это и самое большое зло, поскольку приучает программировать лишь в узких рамках этих тестов.

[Slava V]

Вот хоть подтверждения своим словам то приведете? А то тут пишите - я тут один такой славик крутой и умный и верьте мне на слово.

читайте выше

любое моканье - это тупая потеря времени (т.е. денег)
любое количество юнит тестов НЕ гарантирует что все вместе будет работать

попробуете опровергнуть логически или будете и дальше корчить рожи?

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

и это все доводы, на которые оказался способен self-proclaimed автоматизатор?

извините что потревожил Вашу священную корову, удачи в продаже пирамид!

--------------
"Если задеть человека, то из него выплеснется то, чем он наполнен" (с)

[X37WAL!^]

Вот хоть подтверждения своим словам то приведете? А то тут пишите - я тут один такой славик крутой и умный и верьте мне на слово.

читайте выше

любое моканье - это тупая потеря времени (т.е. денег)
любое количество юнит тестов НЕ гарантирует что все вместе будет работать

попробуете опровергнуть логически или будете и дальше корчить рожи?

ОК, у вас есть класс, не покрытый юнит тестами, который только что кто-то сломал. Он используется в 25 местах, в том числе на самом старте системы. Ни один из ваших интегрированных тестов вообще не заводится, диагностика мутная. Сначала вы потратите время на то, чтобы найти что именно поломано, а потом вы будете чинить этот класс, для проверки каждый раз в процессе запуская всю систему целиком и залезая в каждое из 25 мест. Так можно? Можно, но долго и муторно. Часами процесс починки может измеряться. У меня вон справа сидит любитель так делать, я с натуры пишу...

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

[Мальчик-Одуванчик]

ОК, у вас есть класс, не покрытый юнит тестами, который только что кто-то сломал. Он используется в 25 местах, в том числе на самом старте системы. Ни один из ваших интегрированных тестов вообще не заводится, диагностика мутная.

Если грохается на старте - это вообще подарок. Смотрим из под дебагера пошагово. Такие ошибки легко обнаруживаются и чинятся.
Изменения кода покажут суть ляпа, а дальнейшие тесты поле починки - влияние на оставшиеся 24 места.
Сложнее, когда приложение многопоточное и ошибка есть результат гонок, которые юнит-тестами практически не отслеживаются.
Еще веселее, когда безупречное, с точки зрения юнит-тестов, приложение ложится под слегка возросшей нагрузкой. Как правило, в этом случае основной код правится довольно грубо, однако основное время тратится на бесполезную подгонку юнит-тестов к изменившейся реализации, причем логике самих тестов внимание уделяется уже по остаточному принципу

[Slava V]

ОК, у вас есть класс, не покрытый юнит тестами, который только что кто-то сломал. Он используется в 25 местах, в том числе на самом старте системы. Ни один из ваших интегрированных тестов вообще не заводится, диагностика мутная.

в смысле - все настолько плоxо что даже log4net не работает?
ну тогда оно скорее всего даже не компилируется, так что ошибка вылезет сама

Сначала вы потратите время на то, чтобы найти что именно поломано, а потом вы будете чинить этот класс, для проверки каждый раз в процессе запуская всю систему целиком и залезая в каждое из 25 мест. Так можно? Можно, но долго и муторно. Часами процесс починки может измеряться. У меня вон справа сидит любитель так делать, я с натуры пишу...

мы все еще говорим про девелоперскую машину (не продакшн?)
тогда кто мешает этому любителю пройти дебаггером и посмотреть что происxодит?

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

быстро не будет
юнит тесты - это отсылка каждого кирпича в лабораторию и получение на него сертификата качества (небесплатно,конечно)
при этом за соединение этого кирпича с соседними данная лаборатория не отвечает

[Slava V]

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

да, это классика

[X37WAL!^]

ОК, у вас есть класс, не покрытый юнит тестами, который только что кто-то сломал. Он используется в 25 местах, в том числе на самом старте системы. Ни один из ваших интегрированных тестов вообще не заводится, диагностика мутная.

в смысле - все настолько плоxо что даже log4net не работает?
ну тогда оно скорее всего даже не компилируется, так что ошибка вылезет сама

Ну зачем так грубо... Компилируется. А при старте ну скажем NullReferenceException в строке кода, где этих nulls теоретически может быть штук пять.

[X37WAL!^]

Сначала вы потратите время на то, чтобы найти что именно поломано, а потом вы будете чинить этот класс, для проверки каждый раз в процессе запуская всю систему целиком и залезая в каждое из 25 мест. Так можно? Можно, но долго и муторно. Часами процесс починки может измеряться. У меня вон справа сидит любитель так делать, я с натуры пишу...

мы все еще говорим про девелоперскую машину (не продакшн?)
тогда кто мешает этому любителю пройти дебаггером и посмотреть что происxодит?

Да в общем никто не мешает. Он этим бОльшую часть рабочего времени и занимается. Зашибись, да?

Когда мне сказали, будешь отвечать вот за ЭТОТ код - я потратил два дня чтоб покрыть его юнит тестами и нынче у меня занимает 30-40 секунд на выяснение, не сломалось ли чего в десятке классов. У моего вышеописанного коллеги только дойти в дебаггере до ОДНОГО проблемного места занимает минут десять нажиманий на клавиши.

[Slava V]

ОК, у вас есть класс, не покрытый юнит тестами, который только что кто-то сломал. Он используется в 25 местах, в том числе на самом старте системы. Ни один из ваших интегрированных тестов вообще не заводится, диагностика мутная.

в смысле - все настолько плоxо что даже log4net не работает?
ну тогда оно скорее всего даже не компилируется, так что ошибка вылезет сама

Ну зачем так грубо... Компилируется. А при старте ну скажем NullReferenceException в строке кода, где этих nulls теоретически может быть штук пять.

значит поставить пять проверок на nulls - и выяснить кто из ниx виноват
делов-то...

кстати, в том же c# эта проблема недавно заметно упростилась:

Code: Select all

The null-conditional operator exhibits short-circuiting behavior, where an immediately following chain of member accesses, element accesses and invocations will only be executed if the original receiver was not null:

    int? first = customers?[0].Orders.Count(); // if customers is null, the result is null