Да есть ли какой то критерий, когда нужно выносить проблему на авто тесты. вы что нибудь рукаи вообще тестируете ?

function isAdultAge($age){
    return $age>18;
}

Почему бы нет, вдруг у тебя в $age string прилетит

Конечно стоит. Функция тем более баг имеет

18 лет это уже совершеннолетие

смотря по какому законодательству )

В общем случае стоит тестировать все что содержит бизнес логику. Сетеры и гетеры, одноразовый код, конфиги (хотя тут можно поспорить), скорее всего тестировать не нужно 🙂
Где провести черту - каждый решает для себя сам, у нас есть участки со 100% покрытием, потому что цена ошибка там высока. Есть места где покрытие 30% - проверено основное. Еще стоит хорошо покрывать тестами то, что часто меняется.
Вообщем здравый смысл всегда должен преобладать, нет серебряной пули и универсального рецепта

О знаменитости в чате 🙂
Привет! Спасибо за Infection, мы знатно вдохновились инструментом!

Спасибо вам :)

Для типов есть тайп хинтинг скаляров же

Руками тестируем, конечно. Но руками проверяют корректность интеграции, QA инженеры ищут edge кейсы, и прочее. Вообщем то, проверку чего автоматизировать крайне долго или невозможно.
Хорошей практикой, например, мне кажется писать тест на баг. Возможно коллеги еще что-то посоветуют из более-менее универсальных рецептов

function isAdultAge($age){
    return $age>18;
}

А так лучше тестировать точки входа ИМХО, если ваш сервис начинает делать кучу всего и содержит дофига логики, которая слабо связанна между собой, то тут по принципу единой ответвенности сервис разбивать надо, а не пытаться писать 100500 тестов которые особо ничего не дадут кроме боли, а если это не возможно(нет времени на рефакторинг например) то тут функциональные тесты вам в помощь

Я думаю что неплохим показателем является CRAP:

Change Risk Anti-Patterns (CRAP) Index
The Change Risk Anti-Patterns (CRAP) Index is calculated based on the cyclomatic complexity and code coverage of a unit of code. Code that is not too complex and has an adequate test coverage will have a low CRAP index. The CRAP index can be lowered by writing tests and by refactoring the code to lower its complexity.

чем больше условных конструкций и циклов в методе, тем выше CRAP и тем больше он нуждается в покрытии тестами
если условных конструкций и циклов в методе нет, то возможно его и нет смысла тестировать (трудно представить какой-нить алгоритм без условных операторов и циклом, но наверное такое может быть)
чем лучше метод покрыт тестами там CRAP ниже
но как уже говорил @YantsV, покрытие - не самый достоверный показатель того, что всё протестировано и мутационное тестирование дает более честный показатель

Как можно на серьезных щах обсуждать показатель качества кода под названием crap? 😂

The less crap your code has, the better it is (c) капитан очевидность

что с ним не так, что его лучше не обсуждать?

Название же

Аа)
Ну он так называется:)

Ребята, всем привет!

Вопрос по презентациям - на гугл диске только 3. А остальные будут? :)

Привет! Презентацию Дмитрия не удалось вытащить в pdf нормально. Так что на диске лежит ссылка на onilne версию

А презентации Леши нет?