а их ты как собираешься тестировать юнит тестами?)
Никак, только интеграционными
🐴
Sergey
ну так причем тут доктрина?)
Sergey
у меня все что знает о доктрине лежит в репозиториях (и в read моделях)
Sergey
и покрывается это только интеграционными тестами. И логики там нет.
Sergey
тупо выборки
🐴
Да
🐴
Именно так
Sergey
и вот важный вопрос - что бы логики небыло
Sergey
ты можешь например... просто прогонять какой-нибудь сборщик метрик и просто для некоторых классов контролировать цикломатическую сложность
Sergey
например "у всех репозиториев количество if-ов на метод не должно привышать"
Sergey
(конечно не надо жестко ограничивать себя)
Sergey
тут суть только в уменьшении количества тест кейсов
Sergey
любое ветвление логики - увеличение тест кейсов
Sergey
прячем все if-ы внутри маленьких классов, которые будем покрывать юнит тестами
🐴
Но с доктриной и с файлами у меня просто выбора нет. А тут есть выбор - можно сделать отдельные методы.
Sergey
Sergey
ну мол не понял
🐴
О gitgateway
Sergey
отдельные методы.... которые будут делать.... что?
Sergey
ты можешь сделать например отдельный объект GitResultParser
🐴
Возвращать отдельное свойство отдельной ревизии
Sergey
или что-нибудь эдакое
Sergey
зачем?
Sergey
то есть ты добавишь публичный метод тупо ради тестов?
🐴
Чтобы иметь более гранулярное покрытие тестами
Sergey
лучше написать интеграционный тест чем добавлять публичный метод, который нигде не должен юзаться
🐴
Test induced damage, да
Sergey
в этом как раз суть TDD - писать ровно столько сколько надо для решения задачи
Sergey
ты при помощи TDD придешь к тому что тебе нужен интерфейс GitIGateway
Sergey
и все
Sergey
дальше дробить или нет
Sergey
это уже зависит от задачи
🐴
В целом мне кажется я понял свою ошибку, у меня в голове юнит=класс
Sergey
в твоем случае это лишние слои абстракции которые попросту не будут приносить профита
Sergey
В целом мне кажется я понял свою ошибку, у меня в голове юнит=класс
ошибка многих, я тоже так долгое время думал
Sergey
http://martinfowler.com/bliki/UnitTest.html
Sergey
вот тут очень хорошо расписано про это
Sergey
в особенности про N определений юнит тестов
🐴
Да, в твоем подходе есть преимущество - он тестирует интерфейс целиком как смысловую единицу
🐴
Вместе с поведением
Sergey
в этом видосе про integration tests are scam как раз говорится что тестировать нужно соблюдение объектом контракта. Не отдельные методы, а совокупность
🐴
Дада, я смотрел
🐴
Хороший видос
Sergey
в целом все это больше поиск компромисом между скоростью выполнения и т.д
Sergey
то же 100% покрытие кода тестами не нужно
Sergey
потому что вопервых метрика крайне не эффективная (без мутационных тестов)
Sergey
ну а во вторых многие вещи просто тупо нет смысла покрывать тестами. Они никогда не будут меняться
Sergey
90% норм
🐴
Клево
🐴
Большое спасибо
🐴
Очень познавательная беседа
Ale
https://gist.github.com/mkusher/d8b9a30c53da83f01341bfc6fa218900
Ale
Два хендлера. Делают одно и тоже, написаны немного по-разному
Sergey
годнота
Sergey
а коллекции в ts как выглядят?
Ale
Если просто массивы, то два варианта:
T[]
Array <T>
Sergey
второй канеш
Ale
2 строки победили?) Мне тоже второй нравится)
Sergey
ну я не вижу смысла в классе там где можно лямбдой разрулить
Sergey
так посмотришь, вроде не сильно тошнотворно жс выглядит
Ale
С типами только если
Ale
Иначе будешь объект с массивом складывать
Sergey
потом открываешь что-то типа https://gist.github.com/Enleur/e2a349b805d04a5b3fc39af62e3c46a0 ужасаешься и закрываешь
Ale
I'm back in ussr
Sergey
прошло уже больше 5 лет, а стиль кода на жс у меня не менялся)
Sergey
я правда уже не писал на нем года 2.5 точно
Sergey
но наши фронты продолжают в том же духе все делать
Ale
Поставь им eslint с airbnb конфигом
Ale
Код станет сразу чуть лучше)
Sergey
та надо просто babel с вебпаком протащить на замену requirejs
Ale
Babel не заменяет ж requirejs
Sergey
не дописал предложение
Sergey
вебпак заменяет
Sergey
а ты ts вместе с реактом готовишь?
Alexander
@fes0r спасибо за книжку
WiNNeR
Привет, есть кто ?
WiNNeR
такой вопрос, обязательно ли закрывать соединение к бд ?