Ostatnio był tu wątek dotyczący tego, jak sprawdzać unikalność NIPu klienta. Jednym z rozwiązań było stworzenie CustomerFactory
, która miałaby wstrzyknięte ICustomerRepository
(albo inny serwis domenowy) i zwracałaby encję Customer
po sprawdzeniu, czy NIP na pewno jest unikalny. Ale najważniejszym punktem było to, że Customer
miałby konstruktor oznaczony jako internal
. I teraz pojawia się problem: jak w testach tworzyć klientów, skoro konstruktor Customer
jest niewidoczny w projekcie z testami? Chciałbym mieć takiego DSLa: https://github.com/asc-lab/better-code-with-ddd/blob/ef_core/LoanApplication.TacticalDdd/LoanApplication.TacticalDdd.Tests/Builders/CustomerBuilder.cs Przychodzą mi do głowy następujące rozwiązania:
- Użycie w metodzie
Build
klasyCustomerBuilder
instancjiCustomerFactory
mającej wstrzyknięte zmockowaneICustomerRepository
. Jeśli tylko konstruktor jestinternal
, to raczej nie powinno być problemu. Gorzej, jeśli metody zmieniające stanCustomer
też będąinternal
i żeby je wywołać trzeba będzie korzystać z innych serwisów domenowych. To już będzie niewygodne. - Zamiana wszystkich metod i konstruktorów w projekcie domenowym na
public
. To dość kontrowersyjne i radykalne. - Udostępnienie jakiegoś publicznego konstruktora jedynie na potrzeby testów, za pomocą którego dałoby się wprowadzić encję
Customer
w dowolny stan. Taki konstruktor nie miałby żadnej walidacji, po prostu ustawiałby wszystkie pola i właściwości na to, co zostało przekazane do tego konstruktora. - Użycie
InternalsVisibleTo
. Znów kontrowersyjnie, ale używalibyśmy tych internali tylko w DSLach. W samych testach używalibyśmy wyłącznie publicznego API (serwisów domenowych).
Co byście zrobili? Może jakieś zupełnie inne rozwiązanie? @somekind @Aventus