доклад с конференции http://www.msqadays.ru/При написании unit-тестов на бизнес-логику часто возникают следующие затруднения:тестовые методы называются в стиле TestSomeMethod и являют собой длинную простыню хитросплетений разных сценариев для проверки работы одного метода;значительную часть тестовых методов занимает подготовка и настройка окружения, так что тяжело понять, что же именно проверяется;попытки поместить создание всего окружения в SetUp-методы делают тестовые классы путанными, а отдельные тестовые методы зависимыми друг от друга;рекомендация держать ровно один Assert на тест не выполняется или приводит к огромному дублированию кода;при изменении требований не так-то легко найти какие тесты нужно поправить, и даже найдя их, еще нужно сообразить что и как поправить в длинном витьеватом коде;что делать, если у нескольких тестов есть общая часть, - как ее следует оформить?как "правильно" называть тесты, как их группировать в тестовые классы?как соотносятся