АГ
словно прочитал лекцию на тему "не выкладывали свои проекты в опенсорс - нефиг и начинать"
Size: a a a
2021 January 08
˸A
Читабельности и сопровождаемости. Устойчивость к рефакторингу
Не вижу этих проблем
Вы, наверное, никогда не читали тесты на том же ирдисе или пурскрипт или хаскель, в конце концов
Вы, наверное, никогда не читали тесты на том же ирдисе или пурскрипт или хаскель, в конце концов
I
От чего же, если автор адекватен, то он воспримет советы с пользой для дела. В данном случае, я вижу что метрика изолированности модулей выполнена, значит юнит тесты можно писать. Но не выполнена задача простоты реализации как в БЛ, так и в тестах.
I
Не вижу этих проблем
Вы, наверное, никогда не читали тесты на том же ирдисе или пурскрипт или хаскель, в конце концов
Вы, наверное, никогда не читали тесты на том же ирдисе или пурскрипт или хаскель, в конце концов
Присутствие в мире говно тестов не отменяет наличие качественных
˸A
Присутствие в мире говно тестов не отменяет наличие качественных
Какая у вас метрика говна? Вон человеку выше тесты понятны
I
Ему не понятны, он тролль
I
Просто перенеси все вычисления в конечные тестовые наборы данных
I
Сделай текстовые описания для каждого случая тестирования, которые описывают необходимость каждого набора и его отличие от других.
I
Тогда станет меньше таких вот тестов с временной связанностью, где следующий зависит от предыдущего.
АГ
вообще тесты это вроде внутренняя кухня. для людей есть дока
˸A
Тогда станет меньше таких вот тестов с временной связанностью, где следующий зависит от предыдущего.
Так такой тест как раз и писался, чтоб проверять это в связке: cancelAfterRefund, cancelAfterInvoice и т д
АГ
ну и вообще, опенсорс же, пр в руки и вперед)
I
Так такой тест как раз и писался, чтоб проверять это в связке: cancelAfterRefund, cancelAfterInvoice и т д
Я не отменяю таких вот тестов внутренней интеграции этих зависимостей в БЛ. Но в них тебе надо проверять исключительно моменты этих связок, подготовил данные, проверил конкретный кейс. И обязательно описание кейса, если ты не можешь его сформулировать фразой, то это тоже индикатор проблемы со сложностью домена.
I
Тесты - это те же контроллеры, они предназначены для того, чтобы реализовать передачу данных в sut и сверить результат. А контроллеры должны расти вширь и не иметь цикломатичной сложности.
˸A
Я не отменяю таких вот тестов внутренней интеграции этих зависимостей в БЛ. Но в них тебе надо проверять исключительно моменты этих связок, подготовил данные, проверил конкретный кейс. И обязательно описание кейса, если ты не можешь его сформулировать фразой, то это тоже индикатор проблемы со сложностью домена.
После первого инвойса можно зделать кансел, а можно рефанд, или ещё инвойс, а после каждого из них - ещё, а потом ещё... получается дерево вариаций размножается на каждом шаге. Если под каждую из вершин дерева вариантов готовить отдельные данные, а не использовать firstInvoice, например, то получится простыня из набора (непонятно откуда взятых) данных
I
Ну сделай для этого first invoice отдельный билдер, чтобы он являлся частью набора данных для теста, а не частью sut. Как sut ты его проверишь другим тестом
˸A
Ну сделай для этого first invoice отдельный билдер, чтобы он являлся частью набора данных для теста, а не частью sut. Как sut ты его проверишь другим тестом
Ваш подход к тестам понятен.
Похоже на то, что мне уже другие писали: "больше 1 expect в одном тесте - плохой тон"
Но это догматизм.
Я просто позволю себе не следовать этим догмам
Похоже на то, что мне уже другие писали: "больше 1 expect в одном тесте - плохой тон"
Но это догматизм.
Я просто позволю себе не следовать этим догмам
DT
Тоесть тесты читаемы, просто билдера не хватало
I
Нет, ещё там много логики вычислений в которую надо вникнуть, чтобы понять сценарии тестирования
I
Это не догма, это второе слово в метрике "цикломатичная сложность"