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

есть вменяемое объяснение для чего используется показатель покрытия кода тестами или продолжим «всхлипывать и смеяться»? ;)

для определения того, какой функционал покрыт тестами, а какой еще в них нуждается.

функционал - совокупность того, что может делать продукт

2vostrik

>что Вы подразумеваете говоря «функционал»?

а есть варианты?

дело не в этом

начали мы с этого сообщения, в котором говорится о покрытии кода:

я тебе умный вещь скажу: чем больше кода покрыто тестами - тем меньше осталось покрыть

и затем Вы незаметненько переползли к функционалу:

для определения того, какой функционал покрыт тестами, а какой еще в них нуждается.

я пытаюсь понять к чему бы это, ибо понятия разные

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

слишком длинно и узкоспециализировано (кто знает куда кривая спора выведет), а по смыслу то же самое

далее, раз уж спорим, давайте начнём с определений (без формализма)

как Вы понимаете следующие понятия (применительно к development): test-first, test-last и test-driven

и эти люди называют меня шлангом?

во время разработки (whitebox тестирование) показатель покрытия кода используется разработчиками для оценки того, какой код еще нужно покрывать

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

test-first - тесты пишутся до кода и используются для проверки кода

test-last - тесты _пишутся_ после кода

test-driven - тесты пишутся до кода и используюся для написания кода

как ты понимаешь, я жду от тебя определений test-first test-driven и behavior-driven

во время разработки (whitebox тестирование) показатель покрытия кода используется разработчиками для оценки того, какой код еще нужно покрывать

после того как продукт приходит на blackbox тестирование тестировщик оперирует функционалом, а не кодом.

чувствуете как меняется контекст из-за смены всего одного термина? :)

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

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

1) «blackbox» - тестируем функционал на соответствие интерфейсов спецификациям и на соответствие функций требованиям предъявляемым к ним с точки зрения выполняемых операций и возвращаемых значений;

2) «whitebox» - тестируем ветки кода не охваченные «blackbox»-тестированием для того чтобы быть уверенными что тот или иной кусок кода отработает корректно (например ветка кода, условие и т.д.)

согласны?

и эти люди называют меня шлангом? еще глупые вопросы?

давайте без детских эмоций

>чувствуете как меняется контекст из-за смены всего одного термина? :)

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

«blackbox» - тестируем функционал на соответствие интерфейсов спецификациям и на соответствие функций требованиям предъявляемым к ним с точки зрения выполняемых операций и возвращаемых значений;

«whitebox» - тестируем ветки кода не охваченные «blackbox»-тестированием для того чтобы быть уверенными что тот или иной кусок кода отработает корректно (например ветка кода, условие и т.д.)

согласны?

«whitebox» - тестируем ветки кода не охваченные «blackbox»-тестированием

согласны?

нет, конечно.

как ты понимаешь, я жду от тебя определений test-first test-driven и behavior-driven

test-first - все тесты (или, по крайней мере, значительная часть) пишется до написания кода, после чего пишется код

test-driven - пишется один тест -> пишется код обеспечивающий выполнение этого теста -> пишется следующий тест и т.д.

behavior-driven - определяем список фич, разрабатываем сценарии использования, определяем поведение в сценариях (связываем сценарии с кодом) -> выходим на тестирование

опа-опа, дуэль!

>чувствуете как меняется контекст из-за смены всего одного термина? :)

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

кардинальная разница - функционал должен быть закрыт на 100%, все ветки кода закрыть на 100% можно, но это чудовищно жрёт ресурсы и я ни разу ни в одном продукте такого не видел, как правило процент покрытия 70-90%

>«whitebox» - тестируем ветки кода не охваченные «blackbox»-тестированием

согласны?

нет, конечно.

то есть будете по второму разу одно и то же тестировать? :)

не вижу кардинальности. вижу не очень существенные различия, обусловленные спецификой работы.

не вижу кардинальности. вижу не очень существенные различия, обусловленные спецификой работы.

а Вы вспомните почему не рекомендуется интенсивно применять whitebox тестирование (никогда не видели как тесты начинают после рефакторинга отваливаться?)

[пишем unit-тесты >> пишем код] >> (определяем % покрытия кода и неохваченные участки)  >> тестируем blackbox 

 ^whitebox 

ничего не смущает?

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

[пишем unit-тесты >> пишем код] >> (определяем % покрытия кода и неохваченные участки) >> тестируем blackbox

^whitebox

ничего не смущает?

это по какой схеме разработки у Вас так получается?

по TDD рекомендуется сразу писать blackbox-тесты, более того там всё на этом построено, whitebox - только по небходимости и только в обоснованных случаях

для чего определяем «% покрытия кода»? мне кажется в данной схеме можно эту операцию выкинуть и ничего не поменяется :)

ничего не забыл?

>behavior-driven - определяем список фич, разрабатываем сценарии использования, определяем поведение в сценариях (связываем сценарии с кодом) -> выходим на тестирование

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

>по TDD рекомендуется сразу писать blackbox-тесты, более того там всё на этом построено, whitebox - только по небходимости и только в обоснованных случаях

а расскажи-ка мне определение whitebox и blackbox

% покрытия кода определяем для того чтобы

а) дописать юнит-тестов до требуемого значения

б) выкинуть уже покрытые пути из blackbox

в) определить пути, которым уделить особое внимание при blackbox

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

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

это как раз проблема с whitebox, вот почитайте, особенно обратите внимание на 2-й пункт:

Хрупкие тесты

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

* Чаще всего причиной этому становятся медленные тесты. Если полный набор выполнять слишком долго, то разработчики скорее всего начнут выбирать, когда и как часто запускать полный набор, а все остальное время будут запускать тесты только для того кода, над которым они работают в текущий момент. В зависимости от того, как хорошо до этого были разработаны тесты и прочий код, этот подход может быть успешным и не очень. Если разработчик изменил достаточно много кода, а только потом выполнил общих набор тестов и обнаружил, что тесты не выполняются, он уже не может знать точно, такие сделанные им изменения привели к ошибкам. А это и есть причина того, что разбираться становится сложно и утомительно. Запускайте ваши тесты чаще и они ломаться будут реже!

* Другая причина - неправильное тестирование. Тест «знает» слишком много деталей тестируемого кода, из-за этого при малейших изменениях в тестируемом коде тесты ломаются. Приходится править и тесты, и тестируемый код, что увеличивает нагрузку на разработчиков. Относиться к этому можно двояко - 1) если вы меняете поведение класса, то изменение в тестах прогнозируемы, 2) а вот если вы проводите рефакторинг кода без изменения функциональности, а тесты постоянно ломаются - значит есть повод подумать, как переделать тесты.

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

взято отсюда

это не проблема с whitebox, это проблема с кривыми руками. и я таки жду определений всех ящиков - по-моему тут кто-то путает теплое с мягким.

>behavior-driven - определяем список фич, разрабатываем сценарии использования, определяем поведение в сценариях (связываем сценарии с кодом) -> выходим на тестирование

ничего не забыл?

код пишется там где выходим на тестирование или Вы про что?

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

возможно, но тем не менее разрабатываются они блоками, причём блоками существенно большими чем при TDD

и такой процесс начинает быть сильно навязчивым и раздражающим при использовании маленьких итераций

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

а расскажи-ка мне определение whitebox и blackbox

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

% покрытия кода определяем для того чтобы

а) дописать юнит-тестов до требуемого значения

это порнография, батенька

написание unit-тестов не самоцель, читаем

Тесты – это не вещь в себе. Но часто разработчики впадают в крайность – это ситуация, когда тестам начинают уделять повышенное внимание. Разработчики пишут слишком много тестов, проверяют все и вся. И это однажды перерастает в разработку ориентированную на тесты (testing oriented development anti-pattern). Джемс Гринвуд так описывает этот анти-паттерн: «Когда неопытные или введенные в заблуждение программисты продолжают писать тесты, хотя в этом нет никакого смысла с практической или финансовой точки зрения. При этом они думают, что это и есть TDD и, добавляя в систему все новые и новые тесты, они увеличивают ее стоимость». Думается, что комментировать это определение нет смысла.

взято отсюда

б) выкинуть уже покрытые пути из blackbox

в) определить пути, которым уделить особое внимание при blackbox

у меня устойчивое ощущение что у Вас blackbox тестирование больше связано с приёмочным тестированием, не?

это не проблема с whitebox, это проблема с кривыми руками.

а! и как это коррелирует с тем что Вы написали чуть выше? напомню:

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

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

простите, я не очень понял Вашу мысль, не могли бы её выразить более чётко?

во-первых попробуй уже отвязаться от голой теории TDD ради TDD.

во-вторых в данном примере я под blackbox в основном имею в виду integration testing и regression testing - те вещи, на которые никогда не хватает времени. с чего ты делаешь выводы про smoke test - мне непонятно

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

>это порнография, батенька

это жизнь, сынок.

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

во-первых попробуй уже отвязаться от голой теории TDD ради TDD.

ну-ну, это вообще-то практика :)

забей. это интимные проблемы криворуких разработчиков, не о них речь. а вот с пониманием того, что такое whitebox проблемы есть. любой unit-test это whitebox-тест. особенно тот, который тебе так нравится в TDD.

что именно непонятно?

ровно то что я написал:

простите, я не очень понял Вашу мысль, не могли бы её выразить более чётко?

далее:

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

и причём тут тестирование? :)

во-вторых в данном примере я под blackbox в основном имею в виду integration testing и regression testing

Вы необоснованно сужаете область определения термина blackbox

те вещи, на которые никогда не хватает времени.

хехе, а Вы смелые товарищи как я посмотрю :) не знаю конечно какая у Вас область разработки, но без регрессии и интеграции - это жесть

с чего ты делаешь выводы про smoke test - мне непонятно

мы пока про это ничего не говорили

>>возможно, но тем не менее разрабатываются они блоками, причём блоками существенно большими чем при TDD

и такой процесс начинает быть сильно навязчивым и раздражающим при использовании маленьких итераций

shty * (30.10.2010 19:45:07)

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

>это порнография, батенька

это жизнь, сынок.

в жизни порнография часто встречается, так что никакого противоречия

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

1) мыши кололись, плакали но продолжали есть кактус

2) нафига заказчику знать про то сколько тестируется % кода и как???

3) нафига вообще связывать тестирование операторов и работу QA?

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

>Вы необоснованно сужаете область определения термина blackbox

я?

хехе, а Вы смелые товарищи как я посмотрю :) не знаю конечно какая у Вас область разработки, но без регрессии и интеграции - это жесть

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

мы пока про это ничего не говорили

у меня устойчивое ощущение что у Вас blackbox тестирование больше связано с приёмочным тестированием, не?

shty * (30.10.2010 19:53:45)

1) другой планеты у меня для вас нет

2) например когда он получает не готовый продукт а его часть, которую будет дальше интегрировать самостоятельно

3) к словам не придираемся, да? работу QA можно существенно сократить если выбросить куски с уже покрытым тестами функционалом

4) it depends

а вот с пониманием того, что такое whitebox проблемы есть. любой unit-test это whitebox-тест.

Вы ошибаетесь

1) если рассматривать тестируемую сущность (вплоть до отдельной функции) с точки зрения её публичных интерфейсов - это и есть blackbox, в классическом понимании этого термина

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

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

>>возможно, но тем не менее разрабатываются они блоками, причём блоками существенно большими чем при TDD

и такой процесс начинает быть сильно навязчивым и раздражающим при использовании маленьких итераций

shty * (30.10.2010 19:45:07)

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

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

BDD работает гораздо более крупными мазками

>хехе, а Вы смелые товарищи как я посмотрю :) не знаю конечно какая у Вас область разработки, но без регрессии и интеграции - это жесть

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

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

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

и да, если не хватает времени - значит начальство ставит заранее невыполнимые сроки, разработка должна вестись в спокойном ключе, лучше 10 фич не заимплементить, чем в одной допустить ошибку

и опять мне непонятно, откуда выводы про «без»

а «экономия» это что в Вашем понимании?

1) другой планеты у меня для вас нет

а должна быть?

2) например когда он получает не готовый продукт а его часть, которую будет дальше интегрировать самостоятельно

ну, возможно

3) к словам не придираемся, да? работу QA можно существенно сократить если выбросить куски с уже покрытым тестами функционалом

можно, а можно повысить надёжность, априори не указывая им что тут тестировать - тут не тестировать, тут что важно - верифицирование данных тестирования независимым способом

>и без пройденных регрессии и интеграции с тобой даже никто и говорить не станет, не говоря уж о том чтобы смотреть как оно работает ручками

[тут был фейспалм] регрессия и интеграция тоже бывают ручками. а еще они бывают после тестирования изменений, а не до.

а «экономия» это что в Вашем понимании?

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

>можно повысить надёжность, априори не указывая им что тут тестировать - тут не тестировать, тут что важно - верифицирование данных тестирования независимым способом

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

>whitebox используется только для того чтобы подсмотреть внутреннее устройство и понять где могут ноги отвалиться

можешь называть это greybox-тестированием, но по тестерским понятиям это whitebox в чистом виде:

- ты строишь сам тест на основе анализа кода

- ты используешь уже написанный код

>и без пройденных регрессии и интеграции с тобой даже никто и говорить не станет, не говоря уж о том чтобы смотреть как оно работает ручками

[тут был фейспалм] регрессия и интеграция тоже бывают ручками.

хм, бывают конечно, но в основном для UI и от этого стараются избавиться, то есть сделать всё по-максимум автоматизированным

а еще они бывают после тестирования изменений, а не до.

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

>а «экономия» это что в Вашем понимании?

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

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

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

>whitebox используется только для того чтобы подсмотреть внутреннее устройство и понять где могут ноги отвалиться

можешь называть это greybox-тестированием, но по тестерским понятиям это whitebox в чистом виде:

- ты строишь сам тест на основе анализа кода

- ты используешь уже написанный код

я не пойму к чему Вы аппелируете, потому что процитированная Вами фраза никак не расходится с тем что написали Вы

>можно повысить надёжность, априори не указывая им что тут тестировать - тут не тестировать, тут что важно - верифицирование данных тестирования независимым способом

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

здесь, конечно, не поспоришь, что есть то есть

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

автоматизация ради автоматизации не нужна. flash/flex и богатый UI практически никогда не оправдывают затрат времени на автоматизацию

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

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

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

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

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