Организация модульных тестов в Visual Studio
Мы должны также говорить о понятии, каковы объекты действительно. Когда я прочитал это обсуждение, я получаю впечатление, что большинство людей здесь смотрит на объекты в смысле Анемичная Модель предметной области . Много людей рассматривает Анемичную Модель предметной области как антишаблон!
в богатых моделях предметной области существует значение. Об именно это Доменный Управляемый Дизайн - все. Я лично полагаю, что OO является способом завоевать сложность. Это означает не только техническую сложность (как доступ к данным, ui-привязка, безопасность...) , но также и сложность в бизнес-домене !
, Если мы можем применить методы OO для анализа, смоделируйте, дизайн и реализуйте наши бизнес-проблемы, это - огромное преимущество для пригодности для обслуживания и расширяемости нетривиальных приложений!
существуют различия между Вашими объектами и Вашими таблицами. Объекты должны представить Вашу модель, таблицы просто представляют аспект данных Вашей модели!
Это верно, что данные живут дольше, чем приложения, но рассмотрите эта кавычка от David Laribee : Модели являются навсегда... данными, счастливый побочный эффект.
еще Некоторые ссылки на эту тему:
4 ответа
I do it the same way but I change the default namespace for each test project to match the namespace of the production project. So the tests for class X.Y.Foo are in X.Y.FooTest rather than X.Y.Test.FooTest - it means you need fewer using directives, and generally makes things simpler.
My main reason for wanting to keep the two in separate projects is to avoid either including the tests in the production library or having to ship an untested library. With the separate project structure, you can run unit tests against anything you build. It also makes it easier to look through just the production classes without having twice as many files to look at (when getting the "feel" of a library).
Finally, don't forget that if you need to access internal members when testing, there's always [InternalsVisibleTo].
Я предлагаю сделать как можно меньше проектов модульного тестирования. Причина в том, что каждый созданный вами файл добавляет не менее десяти секунд времени компиляции. В большом проекте он начинает складываться.
Вот структура каталогов, которую я использую:
имя_проекта / branch / trunk / projects / code / codeproject1
имя проекта / ветви / ствол / проекты / код / код проекта2
имя проекта / ветви / ствол / проекты / код / код проекта3
имя проекта / ветви / ствол / проекты / тесты / testproject1
projectName / branch / trunk / Dependencies
projectName / prototypes
projectName / ...
и в testproject1 следующая структура каталогов:
codeproject1 /
codeproject2 /
codeproject2 / web
codeproject2 / web / mvc
codeproject3 /
codeproject3 / support
Я делаю то же самое, за исключением того, что каждый проект находится в своей собственной папке в той же корневой папке. Что-то вроде следующего:
Папка решения
- Папка ProjectA
- Папка ProjectA.Test
- Папка ProjectB
- Папка ProjectB.Test
У меня всегда есть отдельный тестовый проект для каждого проекта. Отчасти мне просто нравится организация, но я также часто сталкиваюсь с ситуациями, когда я решаю разбить библиотеку на собственное решение, чтобы ее можно было повторно использовать в других решениях. В таких случаях наличие у проекта библиотеки собственного отдельного тестового проекта (а не всех тестов в одном проекте) значительно упрощает выделение этой библиотеки.