Действительно ли тестируемость является одной выравнивание для внедрения зависимости?

Сила инъекции зависимостей проявляется, когда вы используете контейнер инверсии контроля, такой как StructureMap. При его использовании вы нигде не увидите "new" - контейнер берет на себя контроль над созданием объекта. Таким образом, все объекты не будут знать о зависимостях.

Сначала небольшой комментарий: инъекция зависимостей = IoC + инверсия зависимостей. То, что имеет наибольшее значение для тестирования и что вы описали, это инверсия зависимостей инверсия.

Вообще говоря, я думаю, что тестирование оправдывает инверсию зависимостей. Но это не оправдывает инъекцию зависимостей, я бы не стал вводить DI контейнер только для тестирования.

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

Если у вас есть DI-контейнер, это происходит автоматически; DI-контейнер действует как фабрика и соединяет объекты вместе.

Прелесть внедрения зависимостей заключается в возможности изолировать ваши компоненты .

Одним из побочных эффектов изоляции является упрощение модульного тестирования. Другой - возможность менять конфигурации для разных сред. Еще одно - это самоописывающая природа каждого класса.

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

Внедрение зависимостей - это просто средство для достижения цели . Это способ включить слабую связь .

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

Контейнер IoC - это еще один инструмент в наборе инструментов, который помогает вам управлять сложностью приложения - и он работает довольно хорошо. Я обнаружил, что это позволяет лучше кодировать интерфейс, извлекая экземпляр из изображения.

На Java можно писать универсальные объекты доступа к данным:

package persistence;

import java.io.Serializable;
import java.util.List;

public interface GenericDao<T, K extends Serializable>
{
    T find(K id);
    List<T> find();
    List<T> find(T example);
    List<T> find(String queryName, String [] paramNames, Object [] bindValues);

    K save(T instance);
    void update(T instance);
    void delete(T instance);
}

Я не могу говорить о LINQ, но .NET имеет универсальные шаблоны, так что это должно быть возможно.

Дизайн тестов здесь всегда зависит от SUT (System Under Test). Задайте себе вопрос - что я хочу тестировать?

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

Если ваш репозиторий выполняет некоторое отображение или бизнес-логику и действует как accessor к базе данных, то это тот случай, когда необходимо провести декомпозицию, чтобы ваша система соответствовала SRP (Single Responsibility Principle). После декомпозиции у вас будет 2 сущности:

1. OrdersRepository
2. OrderDataAccessor

Протестируйте их отдельно друг от друга, разрывая зависимости с помощью DI.

Что касается уродства конструкторов... Используйте DI фреймворк для конструирования ваших объектов. Например, при использовании Unity ваш конструктор:

var repository = new OrdersRepository(new MyLinqDataContext());

будет выглядеть так:

var repository = container.Resolve<OrdersRepository>;