вот в общем и все)

если крако - да, для мака есть maven. Может ошибаюсь но он идет в коробке с jdk

если стоит ждк проверь - mvn -v

ну я знаю, что у меня стоит мавен

но я всегда был убежден, что мавен идет отдельно от jdk

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

на винде точно отдельно нужно maven ставить

вроде и на маке так же

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

открытых неделю назад и незакрытых?)

открытых неделю назад и незакрытых?)

Конечно от цикла зависит.. ищу количество висящих багов за которые не берутся по разным причинам

он тебе версию последнюю ватащит

плохая идея, скажу я вам.

Конечно от цикла зависит.. ищу количество висящих багов за которые не берутся по разным причинам

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

потому что нафиг не надо) проблема пользователя не аффектит, чинить дорого

итерации 2недельные)

штук 15 наберется

плохая идея, скажу я вам.

Почему?

Почему?

если говорим применимо к вебдрайвер 2 то можем получить: 1. новые баги самого вебдрайвера 2. несовместимость с драйвером браузера (т.е. его тоже обновлять придётся) 3. и прочую свистопляску, с которой порой некогда возиться и разбираться

потому если работает стабильно - лучше лишний раз не обновлять.

Ну, вообще динамические депенденси - зло.

Ну, вообще динамические депенденси - зло.

+++

потому если работает стабильно - лучше лишний раз не обновлять.

Так это если уже все есть и работает. А тут речь шла о первичной установке.

Так это если уже все есть и работает. А тут речь шла о первичной установке.

если про первичку - тогда согласен. а на постоянке - уаще не вариант.

Согласен.

если говорим применимо к вебдрайвер 2 то можем получить: 1. новые баги самого вебдрайвера 2. несовместимость с драйвером браузера (т.е. его тоже обновлять придётся) 3. и прочую свистопляску, с которой порой некогда возиться и разбираться

а вот тесткомплит лишён этих недостатков

а вот тесткомплит лишён этих недостатков

раз так - так жеж замечательно.

ну, вот, последний 12.2 ff51 поддерживает, я просто обновил и то и другое и всё

даже скрипты переделывать не пришлось

Коллеги, я за советом. Как вы контролируете тест покрытие? Есть ли тулзы какие

Нет эффектных тулз. Смотря что надо покрывать и какими тестами. :)

Коллеги, я за советом. Как вы контролируете тест покрытие? Есть ли тулзы какие

Есть тулзы для покрытия кода

Остальное, голая аналитика

Есть тулзы для покрытия кода

Вот тут поподробнее

Есть тулзы для покрытия кода

Работают как ?

Так, подробности опустим

Работают как ?

А вот тут поподробнее

Есть тулзы которые норм определяют покрытие юнит-тестов, там 0%, 23%, 100%и т.д. и все это показывают удобно в виде графиков для каждой поддиректории.

Не, я не спорю, что они отлично это показывают.

Я говорю про то, что эта оценка под собой несет.

Счастье и процветание

Все эти тулзы строятся по примерно одному принципу: граф entity внутри приложения и соотношение используемых\неиспользуемых в тестах сущностей.

Это довольно далеко от понимания "покрыто тестами".

И часто к этому не имеет никакого отношения.

Это не говоря уж о том, что багов внутри этих тулз тоже хватает. У нас, например, есть code rule, что пуллреквест не может быть замержен если покрытие тестами падает.

А чтобы имело отношение надо писать методы с нормальной цикломатической сложностью

Ну, по сути, тест покрытие это что то мифическое или можно более менее четко определить, что покрытие кейсами фичи приближено к 100%?

Дело не в цикломатической сложности, а в том, что это банальная проверка ссылок на entity.

А тесты - это прежде всего проверка логики.

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

Все в этом мире не более чем красивая ачивка, в том числе и нормальное тестирование.

Йеп, но не всё в мире создает иллюзию защищенности и протестированности.

Йеп, но не всё в мире создает иллюзию защищенности и протестированности.

Так, вот иллюзии это не хорошо. Как тогда быть?

такая философия пошла, хоть в кабак иди и читай это там)

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

все так, юзлесс метрика

Это не говоря уж о том, что багов внутри этих тулз тоже хватает. У нас, например, есть code rule, что пуллреквест не может быть замержен если покрытие тестами падает.

Так вот, собственно, недавно дебажили почему покрытие тестами упало на пуллреквесте в 1 строчку, с банальным изменением публичности метода. Причем падало оно исключительно при мерже в девелоп, при запуске чека в рамках PR - оставалось на уровне 98.6% При попытке мержа <95%

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

Так, вот иллюзии это не хорошо. Как тогда быть?

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

Так, вот иллюзии это не хорошо. Как тогда быть?

проверять юниты :)

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

Наоборот. При этом все тесты прошли, как бэ.

Ну значит этот метод не был покрыт

Был.

Как он тогда вызвался если стал приватным?

В рамках контроллера, например?

Это не покрытие, например. Покрытие это когда тест напрямую дергает только лишь этот метод и проверяет его вывод.

И?

ERROR: S client not available

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

Чем вызов метода в консоли с input -> output отличается от вызова метода в рамках контроллера с теми же условиями, если иной логики не затрагивается?

Code execution один и тот же.

такая философия пошла, хоть в кабак иди и читай это там)

звучит как призыв (одобряю)

приватный метод невозможно вызвать, вот что

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

Он не может быть вызван извне сущности.

если приватный то да

А когда был публичный - то на него тест должен быть написан

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

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

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

На приватные - нет.

Это нарушение контракта класса и запрещается.

Как связан класс контракт с тестами на приватные функции, простите?

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

Я всем расскажу

Контракт - это набор всех сигнатур публичных функций. Тестировать надо только их вызовы.

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

Ну, если вас не волнует - круто вам. :)

Коллеги, я за советом. Как вы контролируете тест покрытие? Есть ли тулзы какие

На глаз;)

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

А почему это при мерже происходило - вообще для меня загадка. Если базовая ветка предварительно намержена на pull request

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

вот это интересное заявление)

вот это интересное заявление)

Может ты хотел написать что их нужно тестировать _неявно_ ? ;)

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

Годный материал для почитать тоже сойдёт

Годный материал для почитать тоже сойдёт

С покрытием в функциональных тестах все сложно. Там очень быстро комбинаторный взрыв и боль.

А вот юниты - там полегче.

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

Ничем не закончилось, пришлось накидать пару десятков тестов на тот кусок, который ещё не был покрыт (никак не связанный с изменениями), что бы получить обратно 4%.

А вот юниты - там полегче.

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

Так вот, собственно, недавно дебажили почему покрытие тестами упало на пуллреквесте в 1 строчку, с банальным изменением публичности метода. Причем падало оно исключительно при мерже в девелоп, при запуске чека в рамках PR - оставалось на уровне 98.6% При попытке мержа <95%

Там же к публичному появляются всякие неявные штуки от наследования, а-ля toString equals и прочая байда

Может ты хотел написать что их нужно тестировать _неявно_ ? ;)

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

Там же к публичному появляются всякие неявные штуки от наследования, а-ля toString equals и прочая байда

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

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

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