В том и дело что это не похоже на либу, а тупо решение индивидуальной задачи

о, тесты...

не оч полезные

Нет конечно 🙂 Но публичные все равно придется держать актуальными, поэтому "упражнение на прилежность" не избежать в любом случае

а публичная часть либки часто меняется?)

я бы лучше порассуждал на тему "почему ифы в тестах признак того что тесты говно"

В тесты логика какая-то потекла зачем-то

если б было нормальное описание "как работать должно" можно было б побаловаться и реализовать проще) и потом сравнить)

Похоже на курсовую

групповой редьюс

Конечно да.
За полгода использования лишь 2 мелких фикса было, без изменений в публичном апи

OCP соблюдён. Все типы используют extends.
У нас при использовании в объектах sales куча дополнительных полей.
В будущем может и taxes будет, если будет у нас такая задача. Но по задумке, это можно будет "навернуть", не меняя вычисления в totals

Это не частное решение. Там в пдф файле представлена теоретическая модель, которая реализована в коде. Я достаточно поработал в мадженто, чтоб сделать модель достаточно абстрактной и расширяемой для новой функциональности.

К слову, сейчас пилим мульти-пеймент, когда заказ оплачен из нескольких различных источников. В каждом документе (инвойс/рефанд/отмена) надо будет знать, какая часть total к какому источнику payment относится

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

это уже больше в BDD

Нет, любые тесты

любишь в догматизм значит

Нет. Это очевидные выводы

это один из вариантов, со своими плюсами и минусами

Если у тебя сложные тесты, значит ты не умеешь в дизайн