Доступ к данным, модульное тестирование, внедрение зависимостей

Мне нужно создать интерфейс и реализовать его в классе доступа к данным. Также мне нужно будет добавить конструктор в класс бизнес-логики, который будет принимать параметр этого типа интерфейса. Это означает, что в конечном итоге я создам класс доступа к данным в методе приложения Main (), и что-то мне подсказывает, что это не лучший подход (действительно ли нормально, что точка входа должна знать о некоторых вещах, связанных с доступом к данным? Что, если цепочка намного длиннее или цепочек должно быть несколько?)

Напротив! Это лучший подход, по крайней мере, с точки зрения тестируемости.

Единственный способ сделать уровень бизнес-логики тестируемым - изолировать его от уровня доступа к данным, выполнив именно то, что вы думаете.

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

Если цепочка намного длиннее или цепочек несколько, в этом нет ничего страшного (хотя вы можете подумать о свертывании некоторых уровней приложения, если это выйдет из-под контроля). Рассмотрим этот потенциальный код в View приложения Model-View-Presenter, где Presenter имеет зависимость от CustomerService, который имеет зависимость от Repository и зависимость от AccountingService (который также зависит от Repository):

public CustomerView() {
    IRespository       repository        = new ConcreteRepository();
    IAccountingService accountingService = new ConcreteAccountingService(repository);
    ICustomerService   customerService   = new ConcreteCustomerService(accountingService, repository)
    this._Presenter = new CustomerPresenter(customerService);
}

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

Предполагая, что вы используете LINQ to SQL, возможно, вы могли бы использовать шаблон репозитория, чтобы обернуть DataContext в интерфейс, который позже можно смоделировать, что сделает возможным модульное тестирование.

В Интернете есть несколько статей на эту тему, вот одна: http://andrewtokeley.net/archive/2008/07/06/mocking-linq-to-sql-datacontext.aspx

Вот простое решение: вместо прямого вызова класса доступа к данным используйте вспомогательные методы:

  public void insert (...) {
      DataAccess.insert (...);
  }

Теперь вы можете игнорировать эти вызовы. Предлагаю разбить тесты так:

1. Создайте пару тестов, чтобы убедиться, что DataAccess поступает правильно, когда получает правильные параметры.

2. В тестах макета просто соберите параметры, отправленные в insert(). Ни в коем случае не звоните DataAccess.

Тесты в №1 гарантируют, что запись данных в БД будет работать, а тесты в №2 будут гарантировать, что вы вызываете DataAccess с правильными значениями. Последние тесты будут выполняться очень быстро, что упростит тестирование особых случаев и т. Д.

Вам также не нужно постоянно запускать тесты с №1. Только когда вы что-то измените в DataAccess или перед выпуском. Это сделает тестирование эффективным и приятным.