LINUX.ORG.RU
Ответ на: комментарий от vostrik

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

да-да, вот и цитатка имеется:

в зале громкий смех изредка прерываемый всхлипами

;)

shty ★★★★★
() автор топика
Ответ на: комментарий от vostrik

>то есть сделать всё по-максимум автоматизированным

автоматизация ради автоматизации не нужна.

спасибо, кэп :)

>а что такое «тестирование изменений»?

это не про TDD, выдыхай

я спрашивал не «не про что» это а «про что» это :)

>используйте continous integration и ночные сборки забудьте уже про этот страх и ненависть

вам никогда не приходили проекты уже кем-то начатые? вам никогда не приходили проекты которые надо только тестировать?

да всё бывало, только это к предыдущему обсуждению слабо относится

shty ★★★★★
() автор топика
Ответ на: комментарий от shty

>я спрашивал не «не про что» это а «про что» это :)

функциональное тестирование с упором на новые фичи/изменения/рефакторинг

да всё бывало, только это к предыдущему обсуждению слабо относится


ну не слабее внезапного пиара CI. кстати вернемся к нашим баранам: у вас еще не появилось мыслей о том, где используются метрики покрытия кода? кроме трансляции старых и несмешных мифов.

vostrik ★★★☆
()
Ответ на: комментарий от vostrik

>я спрашивал не «не про что» это а «про что» это :)

функциональное тестирование с упором на новые фичи/изменения/рефакторинг

так, а тогда что Вы понимаете под регрессионным тестированием?

кстати вернемся к нашим баранам: у вас еще не появилось мыслей о том, где используются метрики покрытия кода?

для оценки качества тестирования, Вы как мне помнится, не предложили никакого нового прочтения, или я не прав? :)

кроме трансляции старых и несмешных мифов.

это когда было? а то у Вас весь зал смеялся

shty ★★★★★
() автор топика
Ответ на: комментарий от shty

так, а тогда что Вы понимаете под регрессионным тестированием?

мы под регрессионным тестированием понимаем тестирование уже проверенного функционала, к которому требования не изменились

для оценки качества тестирования, Вы как мне помнится, не предложили никакого нового прочтения, или я не прав? :)

не прав, мне опять повторить про оценку прогресса, определение приоритетов в тестировании и прочие очевидные вещи?

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

vostrik ★★★☆
()
Ответ на: комментарий от vostrik

.>так, а тогда что Вы понимаете под регрессионным тестированием?

мы под регрессионным тестированием понимаем тестирование уже проверенного функционала, к которому требования не изменились

тогда Вы себе противоречите

изменения/рефакторинг

едем далее

>для оценки качества тестирования, Вы как мне помнится, не предложили никакого нового прочтения, или я не прав? :)

не прав, мне опять повторить про оценку прогресса, определение приоритетов в тестировании и прочие очевидные вещи?

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

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

точную цитатку пожалуйста

shty ★★★★★
() автор топика
Ответ на: комментарий от shty

тогда Вы себе противоречите

рефакторинг

да, написал на автомате

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

а еще я ношу спортштаны.

точную цитатку пожалуйста

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

shty * (30.10.2010 17:07:53)

vostrik ★★★☆
()
Ответ на: комментарий от vostrik

>точную цитатку пожалуйста

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


ну ладно, зал посмеялся, а Вы то с чем не согласны?

shty ★★★★★
() автор топика
Ответ на: комментарий от shty

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

vostrik ★★★☆
()
Ответ на: комментарий от vostrik

кроме того, что ты игнорируешь реальные применения покрытия кода,

посмотрим:

чем больше кода покрыто тестами - тем меньше осталось покрыть. не больше и не меньше.

это вот это что-ли реальное применение?

и далее

предлагаешь взамен бесполезное в оценке качества работы применение, одновременно называя его «немного формальным»

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

и если рассматривать исходное сообщение:

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

у мен ощущение что Вы несколько не поняли суть сентенций направленных к Вам

shty ★★★★★
() автор топика
Ответ на: комментарий от shty

>это вот это что-ли реальное применение?

именно

бесполезное?


может все-таки расскажешь, как количество покрытого тестами кода говорит о качестве работы программистов?

простите, но я вынужден спросить о Вашей роли в команде


не вижу, чего-то, что вынуждает

у мен ощущение что Вы несколько не поняли суть сентенций направленных к Вам


слушаю внимательно

vostrik ★★★☆
()
Ответ на: комментарий от vostrik

>это вот это что-ли реальное применение?

именно

простите, но в такой трактовке это показатель достойный капитана, 70% показывает что до 100% нам остаётся 30%, да это верный ответ и в то же время бесполезный

бесполезное?

может все-таки расскажешь, как количество покрытого тестами кода говорит о качестве работы программистов?

человек пишет под TDD, ну 100% покрытия достигать и не нужно, но если меньше 70% это скорее всего означает что человек нарушает методологию разработки и в его коде будут встречаться ошибки чаще чем в среднем по команде (из практики)

>простите, но я вынужден спросить о Вашей роли в команде

не вижу, чего-то, что вынуждает

Вы рассуждаете и оперируете понятиями на уровне рядового сотрудника отдела тестирования

shty ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.