функциональность не меняется, меняется способ. Но тебе почему-то придется полностью переделывать тест

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

Ну я предполагаю, что гит не изменит свой интерфейс

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

Один раз я взял от него реальный ответ и играюсь с ним

попробуй написать такой код)

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

Ну и так же поступлю

Выполню реальную команду, скопирую ответ

И вставлю в тест

окей. Ты юзал доктрину?

ну или там.... любой query builder

ты бы стал его мокать?

насколько ты думаешь это адекватно?

Это очень геморно

Но я хз как это правильно сделать

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

просто потому что все что ты делаешь - дублируешь реализацию

А как надо?

интеграционные тесты)

ты берешь и изолируешь всю работу с query builder-ом в маленькую изолированную хрень

и ее тестируешь интеграционными тестами может даже с реальной базой данных

Ну как-то так и приходится

сам по себе query builder полностью на 100% покрыт юнит тестами

точно так же как в твоем примере Shell на 100% работает

и git на 100% работает

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

и вместо того что бы их "подделывать" проще взять и проверить в реальности

и вместо того что бы их "подделывать" проще взять и проверить в реальности

Понял

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

а их ты как собираешься тестировать юнит тестами?)

а их ты как собираешься тестировать юнит тестами?)

Никак, только интеграционными

ну так причем тут доктрина?)

у меня все что знает о доктрине лежит в репозиториях (и в read моделях)

и покрывается это только интеграционными тестами. И логики там нет.

тупо выборки

Да

Именно так

и вот важный вопрос - что бы логики небыло

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

например "у всех репозиториев количество if-ов на метод не должно привышать"

(конечно не надо жестко ограничивать себя)

тут суть только в уменьшении количества тест кейсов

любое ветвление логики - увеличение тест кейсов

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

Но с доктриной и с файлами у меня просто выбора нет. А тут есть выбор - можно сделать отдельные методы.

Но с доктриной и с файлами у меня просто выбора нет. А тут есть выбор - можно сделать отдельные методы.

ты о чем?

ну мол не понял

О gitgateway

отдельные методы.... которые будут делать.... что?

ты можешь сделать например отдельный объект GitResultParser

Возвращать отдельное свойство отдельной ревизии

или что-нибудь эдакое

Возвращать отдельное свойство отдельной ревизии

не понял

зачем?

то есть ты добавишь публичный метод тупо ради тестов?

Чтобы иметь более гранулярное покрытие тестами

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

Test induced damage, да

в этом как раз суть TDD - писать ровно столько сколько надо для решения задачи

ты при помощи TDD придешь к тому что тебе нужен интерфейс GitIGateway

и все

дальше дробить или нет

это уже зависит от задачи

В целом мне кажется я понял свою ошибку, у меня в голове юнит=класс

в твоем случае это лишние слои абстракции которые попросту не будут приносить профита

В целом мне кажется я понял свою ошибку, у меня в голове юнит=класс

ошибка многих, я тоже так долгое время думал

http://martinfowler.com/bliki/UnitTest.html

вот тут очень хорошо расписано про это

в особенности про N определений юнит тестов

Да, в твоем подходе есть преимущество - он тестирует интерфейс целиком как смысловую единицу

Вместе с поведением

в этом видосе про integration tests are scam как раз говорится что тестировать нужно соблюдение объектом контракта. Не отдельные методы, а совокупность

Дада, я смотрел

Хороший видос

в целом все это больше поиск компромисом между скоростью выполнения и т.д

то же 100% покрытие кода тестами не нужно

потому что вопервых метрика крайне не эффективная (без мутационных тестов)

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

90% норм

Клево

Большое спасибо

Очень познавательная беседа

https://gist.github.com/mkusher/d8b9a30c53da83f01341bfc6fa218900

Два хендлера. Делают одно и тоже, написаны немного по-разному

годнота

а коллекции в ts как выглядят?

Если просто массивы, то два варианта: T[] Array <T>

Два хендлера. Делают одно и тоже, написаны немного по-разному

Какой больше нравится?)

второй канеш

2 строки победили?) Мне тоже второй нравится)

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

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

С типами только если

Иначе будешь объект с массивом складывать

потом открываешь что-то типа https://gist.github.com/Enleur/e2a349b805d04a5b3fc39af62e3c46a0 ужасаешься и закрываешь

I'm back in ussr

прошло уже больше 5 лет, а стиль кода на жс у меня не менялся)

я правда уже не писал на нем года 2.5 точно

но наши фронты продолжают в том же духе все делать

Поставь им eslint с airbnb конфигом