Получается тест будет проверять еще и сам класс Commit, причем весьма опосредованно

давай определимся что таки мы тестим)

ты хочешь проверить GitGateway

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

ты хочешь проверить GitGateway

Да

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

это не совсем фабрика

давай составим список консернов

1. Нам надо убедиться что мы создаем только валидные коммиты. То есть все инварианты объекта Commit всегда соблюдаются

Так

соблюдение инвариантов объекта дело самого объекта. Нам нужно реализовать класс Commit таким образом, что бы он не допускал нарушения инвариантов. А это мы будем проверять в юнит тестах на Commit

Так

потому в контексте тестирования GitGateway мы этот пункт вычеркиваем из списка.

Хорошо

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

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

ну тип того да

для начала определись "что надо собственно проверить".

какие сценарии

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

тебе надо составить своего рода чеклист (критерии приемки), который отвечает на вопрос "это работает корректно"

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

подготовить фикстуры (какой-то тестовый набор данных, репозиторий с несколькими коммитами и разными вариантами тегов)

тебе надо составить своего рода чеклист (критерии приемки), который отвечает на вопрос "это работает корректно"

В случае с набором независимых методов это сделать легко, а с классом Commit это сильно сложнее

В случае с набором независимых методов это сделать легко, а с классом Commit это сильно сложнее

ну так ты не методы тестить должен. Ты тестишь юнит.

ну то есть... что бы ты не сделла с объектом, инварианты не должны нарушаться

пример

class User { private $email; private $password; public function __construct(string $email, string $password); }

тут простой инвариант - поля email и password не могут быть пустыми

Это будет интеграционный тест тогда. Если тест фейлит, это не дает тебе точной информации о том, что именно сломалось.

и обязательны

Это будет интеграционный тест тогда. Если тест фейлит, это не дает тебе точной информации о том, что именно сломалось.

почему интеграционный?

почему интеграционный?

Потому что он зависит минимум от двух классов, не понятно, где ошибка

Потому что он зависит минимум от двух классов, не понятно, где ошибка

погоди погоди

какая ошибка?

Это будет интеграционный тест тогда. Если тест фейлит, это не дает тебе точной информации о том, что именно сломалось.

Вот эта

так

у тебя есть класс Commit и тест CommitTest

и этот тест гарантирует тебе на 100% что "кривой коммит" сделать нельзя

это будет всегда валидный объект

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

брошенное из конкретного места

а стало быть в контексте класса GitGateway тебе не надо вообще об этом париться

если у тебя при парсинге инфы будет говно, говно попадет в Commit и тест упадет

тест для GitGateway не изолирован

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

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

а это уже другие штуки

Или вот, пропал последний символ хеша коммита - кто виноват? Какой класс из двух?

это не тестирование самого Commit

О том и речь

погодь

дай договорю

ты же не собирался при тестировании GitGateway тупо проверять количество коммитов?

Тест покрывает слишком большой объем кода, вот что меня смущает

ты же не собирался при тестировании GitGateway тупо проверять количество коммитов?

Собирался проверять логику парсинга

Тест покрывает слишком большой объем кода, вот что меня смущает

это интеграционный тест, он так и должен делать

Собирался проверять логику парсинга

если бы вместо инстанса Commit тебе возвращался бы plain array?

ну мол без объектов, классов и т.д

что-то поменялось бы?

а если stdClass[]?

это интеграционный тест, он так и должен делать

Разве не в этом смысл тдд -чтобы делать тестируемую архитектуру? Слова "это интеграционный тест" для меня звучат как "я не сумел сделать достаточно тестируемый дизайн"

Разве не в этом смысл тдд -чтобы делать тестируемую архитектуру? Слова "это интеграционный тест" для меня звучат как "я не сумел сделать достаточно тестируемый дизайн"

.....ну так в твоем этом GitGateway и логики то нет что бы ее тестировать

если бы вместо инстанса Commit тебе возвращался бы plain array?

Я не хочу аррей, я хочу набор отдельных методов, возвращающих примитивные типы

Я не хочу аррей, я хочу набор отдельных методов, возвращающих примитивные типы

да погоди ты со своим идеализмом

я тебе идею хочу показать

Оке :)

у тебя есть метод возвращающий данные. У данных есть тип. Какой - не важно

array, stdClass или Commit

ты тупо вериваешь данные

Ок ок

ты не проверяешь сам Commit

ты проверяшь что твой GitGateway с Commit правильно работает

что до TDD - TDD заканчивается для GitGateway на введении интерфейса оного. Все. Дальше интеграционные тесты.

именно тесты. У интеграционных тестов и юнит тестов разное назначение

банальный пример - у тебя есть метод, который пишет в файл. Как ты его изолируешь?

введешь какой-то отдельный объект с интерфейсом Writer

так?

Ну наверно

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

Да

А как ты будешь писать штуку, которая будет этим самым писателем?

для нее городить еще одну обстракцию и уходить в бесконечную рекурсию как-то не хочется

Заставлю писать в файл

И проверю его состояние до и после

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

Да

ну вот это уже не совсем юнит тест, поскольку ты начинаешь работать с внешним миром (прям вообще внешним)

теперь пример с гейтвеем. Ты там используешь Shell

или что там для выполнение команд

мы можем написать полностью изолированный тест на наш GitGateway, что бы проверить, что собственно мы пытаемся выполнить.

однако... какой профит от такого изолированного теста? Что он проверят на самом деле?

https://github.com/f3ath/git-changelog/blob/master/src/Git/ShellGit.php#L43

например вот

мы можем этот самый Shell замокать

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

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

Проверяем парсинг ответа настоящего гита

Проверяем парсинг ответа настоящего гита

но шелл то у нас замокан

Да

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

Логика парсинга изолирована