The Art of Unit Testing

общий подход
https://habr.com/ru/post/82842/
почитать дополнительно
Вопрос: Как узнать какой код уже протестирован?
Покрытие кода тестами можно проверить с помощью различных утилит. Для начала могу посоветовать PartCover.

Вопрос: Как же мне протестировать взаимодействие с базой данных, работу с SMTP-сервером или файловой системой?
Действительно, тестировать это нужно. Но это делается не модульными тестами. Потому что модульные тесты должны проходить быстро и не зависеть от внешних источников. Иначе вы будете запускать их раз в неделю. Более подробно об этом написано в статье «Эффективный модульный тест».

Вообще, тесты находятся в отдельной библиотеке и компилируются в .dll файл. Эти тесты можно запускать разными способами:

1. У xUnit-а есть консоль для запуска тестов и GUI. Оба приложения на вход принимают .dll с тестами.
2. Плагин к Visual Studio. Например, очень удобно использовать ReSharper.
   Ага, плюс для VS есть еще TestDriven.NET
   
   

http://qaru.site/questions/190109/automated-unit-testing-why-what-which
Можем ли мы также протестировать GUI с автоматическим модульным тестированием или это просто бизнес-логика?

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

Однако существует много шаблонов проектирования, которые могут помочь вам извлечь всю логику GUI в тестируемые классы: Modev-View-Controller, Model-View-Presenter, Application Controller, Model-View-ViewModel и т.д.

Вы можете выполнять автоматические тесты всего приложения через такие интерфейсы, минуя только часть рендеринга GUI. Такие тесты называются подкожными испытаниями, но считаются интеграционными испытаниями, а не модульными тестами.

(общий подход. пример для питона - unittest)
https://www.youtube.com/watch?v=ptssYZR4kus

Автоматизированное тестирование
https://gist.github.com/codedokode/a455bde7d0748c0a351a
Юнит-тесты хорошо тестируют такой код, который содержит какую-то логику. Если в коде мало логики, а в основном содержатся обращения к другим классам, то юнит-тесты написать может быть сложно (так как надо сделать замену для других классов и не очень понятно, что именно проверять?).
Интеграционные тесты тестируют какой-то компонент системы, обычно состоящий из многих модулей (классов или функций). Например, для блога мы можем тестировать, что при вызове функции сохранения поста в базе данных появляется этот пост, у него верно проставляются теги, число комментариев равно нулю. А при добавлении комментария оно увеличивается на один. Заодно, можно протестировать, например что пост с незаполненным названием не сохраняется.
Для того, чтобы избежать ошибок и не зависеть от внешних условий, интеграционное тестирование производится в контролируемом окружении. Например, перед каждым тестом создается временная база данных с заранее подготовленными записями (к примеру, пользователями блога), очищаются папки для хранения временных файлов, а вместо запросов к внешним сервисам используется заглушка, возвращающая заранее подготовленные ответы.
Если проводить аналогии, например с тестированием авиадвигателя, то юнит-тесты - это тестирование отдельных деталей, клапанов, заслонок, а интеграционное тестирование — это запуск собранного двигателя на стенде.
Тестирование API
Тестирование GUI
GUI тесты еще называют End-to-End (E2E) или приемочные (aceptance) тесты.
Обычно GUI тестируется с помощью скриптов, которые описывают последовательность действий и проверяют ожидаемый результат. Например, скрипт тестирования формы регистрации может работать по такому алгоритму:
много интересной информации - см статью (в первую очередь - про сайты)

• MSTest (Если у вас уже есть Visual Studio Professional или Team System, есть встроенная модульная система тестирования, известная как MSTest.)
• xUnit.net (Если вы ищете бесплатную инфраструктуру тестирования модулей с открытым исходным кодом, я бы порекомендовал xUnit.net)

https://www.youtube.com/watch?v=1CeMd3BzYzY
тесты для VM - 3ее видео: https://www.youtube.com/watch?v=PHZRHo06Fl4