я наверное просто не до конца понимаю, что для вас приватное, а что публичное)

приватное это метод у которого приписан модификатор private

у вас джава, очевидно)

По юнит тестированию есть материал какой?

Даже не знаю, я вот это все постигал практикой, форумами, статьями и мануалами по phpunit

Друзья, прошу вас, не уходите в холивар. Поставлю вопрос так, как правильнее организовывать это самое покрытие? Юниты, функциональное и тп. Как понять, что вот мы написали кейсы и фича готова к релизу (ну при условии успешного прогона кейсов конечно)

Это твоя экспертиза и чуйка, алилуя

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

Есть что почитать? Что бы простые вопросы сразу отпали

у вас джава, очевидно)

А у вас какое определение приватного ?

Ну, btw у нас немного разные 'private', ибо я так понимаю, что Павел всё таки про свои джавистские штучки рассказывает.

В рубях немного по другому работает, но в данном случае не принципиально.

А у вас какое определение приватного ?

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

вопрос в том, чего вы хотите достичь. зачем вам считать покрытие, для чего вы это хотите использовать?

Что бы фича делалась, а мы знали что все покрыто кейсами и можно все заавтоматизировать

На счет материалов хз, просто есть метод и есть тест проверяющий как отрабатывает это метод, все

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

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

Ну вот если метод внутренний то его не надо тестировать. Иначе это нарушение инкапсуляции.

Класс должен быть покрыт так чтобы можно было все приватные методы переписать и не трогать ни строчки кода тестов.

Что бы фича делалась, а мы знали что все покрыто кейсами и можно все заавтоматизировать

Все покрыть не возможно

Что бы фича делалась, а мы знали что все покрыто кейсами и можно все заавтоматизировать

В целом выглядит так: 1) Фича покрывается тест-кейсами 2) Тесткейсы проходят ревью и признаются достаточными (т.е. покрывающими "полностью" всю значимую логику) 3) Тесткейсы автоматизируются. 4) Тесткейсы актуализируются по мере изменения фичи. Win.

Вероятно, однако учитывая что они нигде не инициализируются это не должно явно влиять на code coverage.

На хабре статья была вот совсем не давно про что-то подобное. Чуваки что-то сделалось и понеслось:)

Ну вот если метод внутренний то его не надо тестировать. Иначе это нарушение инкапсуляции.

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

В целом выглядит так: 1) Фича покрывается тест-кейсами 2) Тесткейсы проходят ревью и признаются достаточными (т.е. покрывающими "полностью" всю значимую логику) 3) Тесткейсы автоматизируются. 4) Тесткейсы актуализируются по мере изменения фичи. Win.

Вот тут встаёт вопрос как бы это все грамотно контролировать

На хабре статья была вот совсем не давно про что-то подобное. Чуваки что-то сделалось и понеслось:)

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

Вот тут встаёт вопрос как бы это все грамотно контролировать

Ежовыми рукавицами.

Вот тут встаёт вопрос как бы это все грамотно контролировать

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

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

Покрытие не подразумевает проверку всех возможных сценариев.

Покрытие не подразумевает проверку всех возможных сценариев.

да, я к тому что могут быть ненужные и не быть нужных

и никакая тула этого не поймет

Ну, это да. Про это же я говорил в самом начале спора.

потому что бизнесовые требования и их понимание зависят от человека)

Ну вот если метод внутренний то его не надо тестировать. Иначе это нарушение инкапсуляции.

Напиши тесты внутри класса ;) чой-то не надо тестировать. Ты это ещё про чёрный ящик скажи - если мы не знаем как реализовано и нам недоступно - тестировать не будем.

Ну для этого же есть приоритеты

Вот тут встаёт вопрос как бы это все грамотно контролировать

Из практики, контролировать только так: 0) контролируешь как можешь, и про это 1) рассказываешь где-нибудь на форуме или в чате. Обязательно найдутся умники которые будут тебе доказывать что ты все делаешь неправильно и надо вот по другому. Их советы систематизируешь, переписываешь свои тесты и переходишь к пункту 1).

Тулза нужна что бы все это наглядно видеть

И при возрастающем объеме ничего не пропустить

Есть аналитика

где-то когда-то был какой-то доклад про покрытие UI тестами, где рисовали что проверяется, а что нет

Без нее ни куда

но так не вспомню, и это не совсем то

Линкуйте тесты с бизнестребованиями.

И будет вам радость. ;3

Напиши тесты внутри класса ;) чой-то не надо тестировать. Ты это ещё про чёрный ящик скажи - если мы не знаем как реализовано и нам недоступно - тестировать не будем.

Что за тесты внутри класса?

Линкуйте тесты с бизнестребованиями.

как вспомню так вздрогну)

зачем ты так)

:D

Ну, люди сами этого хотят.

хотя для всяких статистик да это отлично подходит

да, я к тому что могут быть ненужные и не быть нужных

Звучит как тесты, ради тестов

Из практики, контролировать только так: 0) контролируешь как можешь, и про это 1) рассказываешь где-нибудь на форуме или в чате. Обязательно найдутся умники которые будут тебе доказывать что ты все делаешь неправильно и надо вот по другому. Их советы систематизируешь, переписываешь свои тесты и переходишь к пункту 1).

Ты не прав, все работает по-другому!

Тулза нужна что бы все это наглядно видеть

Знаешь почему ещё нет хорошо работающего искусственного интеллекта?

Звучит как тесты, ради тестов

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

Ты не прав, все работает по-другому!

NO U!

Ну, люди сами этого хотят.

Не, ну я не хочу наступать на грабли которые прошли другие, отсюда и возник вопрос: как это делаете вы?

Не, ну я не хочу наступать на грабли которые прошли другие, отсюда и возник вопрос: как это делаете вы?

не делаем никак, потому что в лично моих процессах это не нужно

профита нет

Функциональными я покрываю на глаз несколько самых частых кейсов.

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

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

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

Было предположение что это хороший выход

Не, ну я не хочу наступать на грабли которые прошли другие, отсюда и возник вопрос: как это делаете вы?

у тебя есть спека?

у тебя есть спека?

Да

Функциональными я покрываю на глаз несколько самых частых кейсов.

Все остальное юниты?

Не, ну я не хочу наступать на грабли которые прошли другие, отсюда и возник вопрос: как это делаете вы?

Есть кодкаверейдж, есть бизнес требования

Все

могу рассказать, как когда-то делал) 1. берешь спеку 2. покрываешь требования кейсами, которые покрывают основные бизнесовые сценарии 3. заводишь бизнес-требования в систему 4. заводишь тест-кейсы в систему 5. линкуешь 6. баги, которые не покрылись требованиями, превращаешь с помощью аналитиков в новые требования 7. профит

Все остальное юниты?

Юниты, и совсем чуть чуть приемочных.

Дальше лезть, только пиздец себе устроишь

могу рассказать, как когда-то делал) 1. берешь спеку 2. покрываешь требования кейсами, которые покрывают основные бизнесовые сценарии 3. заводишь бизнес-требования в систему 4. заводишь тест-кейсы в систему 5. линкуешь 6. баги, которые не покрылись требованиями, превращаешь с помощью аналитиков в новые требования 7. профит

Почему ушёл от этого?

Не, ну я не хочу наступать на грабли которые прошли другие, отсюда и возник вопрос: как это делаете вы?

Вот смотри, зачем ты нужен команде, если они могут найти тулзовину, которая это все делает автоматически? (Это к вопросу об AI)

В остальном все как и было выше описано: ревью и проецирование понимания юзкейсов.

Почему ушёл от этого?

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

ERROR: S client not available

Ни чего не гарантирует качество продукта

И ни что

И ни кто

В таком случае расходимся

А зачем тогда работать, если это все случайность?

окей, оно не способствует качеству продукта

Мы безсмыслены

у тебя кейсы написаны, требования залинкованы

и чо

Ну в целом мысль верная, далеко не все кейсы и требования стоит покрывать

Тесты не написаны :) профит!

во-первых под это нужен отдельный человек, если у тебя большой проект, это ресурсы

А только самые важные и ломающиеся

во-вторых ты сидишь и как баран все это пишешь и линкуешь, это абсолютно идиотская работа

пока ты это пишешь и линкуешь мог бы потестировать и автоматизировать это все

если у тебя итеративная разработка и итерации короткие, это вообще полная бесполезность)

Это тоже не гарантирует качество продукта

Что руками, что авто

Тсс! Зачем ты ломаешь чужой мир!? Что ты с ним и потом будешь делать?

я тебе про гарантию уже ответил выше и исправил фразу)

никто и ничто тоже слитно пишутся)

Это тоже не гарантирует качество продукта

А что у тебя понимаешься под качеством?

не цепляйся к словам плиз)

гарантии на Северном кладбище так-то

никто и ничто тоже слитно пишутся)

После 10 литров пива включается автоисправленте

Так что пох ^_^

а ты силен)

Не, недогон еще

почему ты считаешь, что покрытие для тебя будет полезным мероприятием? какую проблему ты хочешь решить?

Хм, из всего выше сказанного, подвожу черту. Тестовое покрытие вещь довольно условная. При написании кейсов стоит основываться на основных юзкейсах и здравом рассудке (то есть понимании самой фичи)

Хм, из всего выше сказанного, подвожу черту. Тестовое покрытие вещь довольно условная. При написании кейсов стоит основываться на основных юзкейсах и здравом рассудке (то есть понимании самой фичи)

да, все так

Хм, из всего выше сказанного, подвожу черту. Тестовое покрытие вещь довольно условная. При написании кейсов стоит основываться на основных юзкейсах и здравом рассудке (то есть понимании самой фичи)

да