Александр Рыжов

Рискую повториться, но позволю описать свое видение.
Можно выделить несколько случаев, когда удобно использовать интерфейсы:

• Абстракция, предполагающая несколько одновременно используемых реализаций. Например IEnumerable или как пример с паттерном "Стратегия" в первом комментарии.
  
• Несколько взаимозаменяемых реализаций одной абстракции. Например логгер, можно логировать в файл, в табличку на форме, в БД.
  
• Замена для тестирования. Хотя при желании это можно сделать и с виртуальными методами, но как правило, с интерфейсами удобнее, с учетом множественной реализации нескольких интерфейсов, но наследование только от одного базового класса, да и базовая реализация как правило тянет за собой клубок зависимостей.
  
• Для следования принципу инверсии зависимостей. Очень рекомендую ознакомиться с принципами SOLID, два из которых как про интерфейсы - принцип инверсии зависимостей и принцип разделения интерфейсов. Если кратко про инверсию - потребители должны зависеть от абстракции, а не от реализации, в том числе на уровне сборок. Чтобы сократить и упорядочить зависимости между сборками, как правило выделяют сборку с интерфейсами и контрактами, которую используют сборки с реализацией, сборки потребители и сборки с тестами.
  

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

Для тестирования DAL, если он полностью использует для сохранения и доступа к данным только методы EntityFramework, можно не использовать реальную базу, а воспользоваться Effort. Но для этого необходимо создать тестовый DbContext, который бы использовал эту библиотеку.
DAL.Test должен референсить все, что необходимо для создания реального тестируемого класса (например репозитория) и фейка для DataContext, который бы внутри себя использовал Effort.

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

Для тестирования репозитория, если он полностью использует для сохранения и доступа к данным только методы EntityFramework, можно не использовать реальную базу, а воспользоваться Effort. Но для этого необходимо создать тестовый DbContext, который бы использовал эту библиотеку. В вашем примере не очень понятно с какой БД вы работаете, т.к. если у вас в app.config нет ConnectionString, то не совсем понятно как работает ваш тест.

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

Я так понимаю речь не только про инструменты, но и про подходы, очень рекомендую книжку
The Art Of Unit Testing с примерами на C#

Также очень рекомендую FakeItEasy, после Moq кажется более интуитивным