Testy bez I/O

Jednym z największych korzyści płynących z Architektury Portów i Adapterów jest możliwość tworzenia kilku adapterów do jednego portu. Możemy to robić, na przykład, na potrzeby testów. Dzięki takiemu podejściu możemy pisać szybkie testy bez dotykania I/O, które będą testowały logikę biznesową naszej aplikacji.

Odwrócenie zależności

Załóżmy, że mamy taką standardową sytuację: CustomerService wstrzykuje CustomerRepository.CustomerRepository dziedziczy po JpaRepository, czyli implementacja tego repozytorium jest realizowana przez Spring Data.W takim przypadku, żeby odwrócić zależność tak, żeby nasza logika biznesowa nie zależała od innych warstw, musimy odciąć nasz serwis od implementacji repozytorium, które pochodzi z warstwy dostępu do danych. Możemy to osiągnąć za pomocą interfejsu.

Czyli zamiast tworzyć interfejs, którego implementacja jest wykonywana przez jakąś bibliotekę, np. Spring Data, sami bierzemy na siebie odpowiedzialność za implementację tego interfejsu.

Wtedy nasz CustomerService może wstrzykiwać np. takie repozytorium:

public interface CustomerRepository {

    boolean existsByEmail(String email);

    Customer findById(UUID id);

    Customer save(Customer customer);

    boolean existsById(UUID id);
}

Co nam to dało?!
To, że teraz nasza logika biznesowa nie zależy od warstwy dostępu do danych. Oczywiście możemy to wykorzystać!

Adapter na potrzeby testów, czyli testy bez I/O

Na potrzeby testów możemy stworzyć osobny adapter (implementację) dla portu (repozytorium). Najłatwiej będzie zaimplementować repozytorium jako HashMap lub ConcurrentHashMap. Java pozwala łatwo dodawać takie obiekty do mapy i usuwać je stamtąd. Będzie działało o niebo szybciej niż korzystanie ze zwykłej bazy i ładownie kontekstu Springa 🙂

public class InMemoryCustomerRepository implements CustomerRepository {

    private final Map<UUID, Customer> store = new ConcurrentHashMap<>();

    @Override
    public boolean existsByEmail(final String email) {
        return store.values().stream()
                .anyMatch(c -> c.getEmail().equals(email));
    }

    @Override
    public Customer findById(final UUID id) {
        return store.get(id);
    }

    @Override
    public Customer save(final Customer customer) {
        store.put(customer.getId(), customer);
        return customer;
    }

    @Override
    public boolean existsById(final UUID id) {
        return store.containsKey(id);
    }

    public void deleteAll() {
        store.clear();
    }
}

Oczywiście, w CustomerService nic się nie zmienia, a my możemy sobie tworzyć ten obiekt w testach bez potrzeby ładowania kontekstu Springa, przy pomocy konstruktora. Dlatego właśnie zaleca się wstrzykiwanie przez konstruktor!

class CustomerServiceTest {

    private final InMemoryCustomerRepository customerRepository = new InMemoryCustomerRepository();
    private final CustomerService customerService = new CustomerService(customerRepository);
//...

Dalej testy będą takie same jakbyśmy wstrzykiwali nasz CustomerService, bo przecież mamy jego instancje, tylko że sami ją tworzymy przy pomocy konstruktora.

Adapter w kodzie źródłowym

Oczywiście, później w kodzie źródłowym utworzymy kolejną implementację dla tego portu, czyli zrobimy kolejny adapter. Co ważne, jednak można to odroczyć w czasie i na początku napisać i przetestować logikę biznesową. A dopiero potem podpiąć bazę danych itp.

W kodzie źródłowym repozytorium prawdopodobnie będzie już korzystać z bazy danych, a my możemy korzystać z dobrodziejstw, jakie oferują nasze frameworki. Warto zwrócić uwagę, że implementujemy tylko te metody, które faktycznie będą używane w naszym kodzie źródłowym, a nie wszystkie. Jeśli nie pozwalamy na usuwanie zasobów, to nie mamy w repozytorium metody deleteAll(), w przeciwieństwie do tego, jakbyśmy korzystali z JpaRepository. Oczywiście, w adapterze, który powstał na potrzeby testów, taką metodę możemy sobie zaimplementować.

Jak zaimplementować w kodzie źródłowym to repozytorium, aby nie tracić korzyści płynących z naszych frameworków? Możemy wewnątrz naszej implementacji repozytorium stworzyć interfejs, który będzie implementował JpaRepository i wstrzyknąć go do naszej implementacji.

@Repository
class SqlCustomerRepository implements CustomerRepository {

    private final JpaCustomerRepository jpaCustomerRepository;

    SqlCustomerRepository(JpaCustomerRepository jpaCustomerRepository) {
        this.jpaCustomerRepository = jpaCustomerRepository;
    }

    @Override
    public boolean existsByEmail(final String email) {
        return jpaCustomerRepository.existsByEmail(email);
    }

    @Override
    public Customer findById(final UUID id) {
        return jpaCustomerRepository.findById(id)
                .orElseThrow(() -> new CustomerNotFoundException(id));
    }

    @Override
    public Customer save(final Customer customer) {
        return jpaCustomerRepository.save(customer);
    }

    @Override
    public boolean existsById(final UUID id) {
        return jpaCustomerRepository.existsById(id);
    }
}

@Repository
interface JpaCustomerRepository extends JpaRepository<Customer, UUID> {

    boolean existsByEmail(String email);
}

Podsumowanie

Jeśli nasza aplikacja ma bogatą logikę biznesową, warto taką logikę odseparować od pozostałych warstw naszej aplikacji. Pozwala to w łatwy sposób testować serce naszej aplikacji, dzięki temu, że możemy na potrzeby testów tworzyć osobne adaptery. Sprawia to, że nasze testy są o wiele szybsze i nie potrzebują kontekstu Springa. Co więcej, testy bez dotykania I/O i ładowania kotenstu Springa zachęcają do korzystania z Test Driven Development, czyli pisania pierwszych testów, a potem kodu źródłowego.

Oczywiście, w powyższym wpisie pokazałem, jak można odciąć serwis od repozytorium, bo to najczęstszy problem. Jednak możemy w ten sposób postępować z każdą klasą, która wstrzykuje jakiś bean dotykający z I/O. Pamiętajmy, że porty i adaptery to tylko idea!