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

Рекомендую беплатную книжку от SyncFusion WPF Succinctly. Так же ее можно бесплатно скачать с их официального сайта, но необходимо зарегестрироваться.

Как показал мой опыт, использование Prism - из пушки по воробьям. Даже в больших проектах обходился своими асбтракциями, согласен с предыдущими комментариями, очень рекомендую Autofac. Пример использования его с MVVM описывал тут.

Главное все зависимости инъектить через конструктор, и ViewModel во View, и Autofac будет делать все остальное за вас.

Рекомендую воспользоваться контейнером зависимостей, например Autofac, подробнее с примерами можно посмотреть тут

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

• Абстракция, предполагающая несколько одновременно используемых реализаций. Например 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 кажется более интуитивным

По ссылке Станислава, у меня решилось так

var uriSchemePack = PackUriHelper.UriSchemePack;
if (Application.Current == null)
{
    var application = new Application();
}

По поводу удаления истории из репозитория можно попробовать создать новый репозиторий, перенеся нужные файлы с историей, для этого была утилита hg convert. Вот на вскидку, что нашел www.zachburlingame.com/2011/05/extract-directory-f...

Настроив получение пакетов on demand, не забудьте чтобы nuget сервер был доступен при сборке на CI-сервере. Либо как альтернативу можно рассмотреть поднятие локального nuget-сервера, чтобы не зависеть от проблем с интернетом.

Есть еще альтернатива WCF duplex, но у него есть ряд особенностей, которые нужно учитывать:
1. Для использования через http требует создания отдельного обратного канала, поэтому лучше использовать net.tcp
2. Для поддержания открытых обратных каналов необходимо вручную реализовать пинг

Обидно, что для такой, казалось бы типовой задачи Microsoft не дал удобный механизм из коробки, wcf но все равно приходится подкручивать и доводить до ума