Тестовые проекты в решении
Взгляните на это:
>>> a = 256
>>> b = 256
>>> id(a)
9987148
>>> id(b)
9987148
>>> a = 257
>>> b = 257
>>> id(a)
11662816
>>> id(b)
11662828
EDIT: Вот что я нашел в документации Python 2, «Plain Integer Objects» (То же самое для Python 3 ):
Текущая реализация хранит массив целых объектов для всех целых чисел от -5 до 256, когда вы создаете int в этом диапазоне, на котором вы просто возвращаетесь ссылку на существующий объект. Поэтому должно быть возможно изменить значение 1. Я подозреваю, что поведение Python в этом случае не определено. : -)
blockquote>
7 ответов
В нашем текущем проекте мы решили поместить все модульные тесты в отдельные проекты. Код приложения и тесты находятся в том же решении, но по крайней мере мы можем создать (и развернуться), версия без кода модульного теста.
оборотная сторона этого - до сих пор была то, что иногда Ваши модульные тесты не могут достигнуть определенных членов кода приложения (защищенный и внутренности), но которые обычно приводят нас обнаруживать, что наш дизайн мог быть улучшен.
И я предполагаю, что должен указать на подобный поток Здесь с большим количеством ответов по той же/подобной теме.
Я всегда сохранял их как часть решения - они - в конце концов, часть решения. У Вас может быть несколько решений, хотя для разных подходов к просмотру Ваших проектов, таким образом, решение без теста может быть тем, что Вы хотели бы создать для некоторых случаев.
Наш тестовый код не поставлется, но они - часть решения в целом. Наш разработчик выделяет опытные сборки и базовые компоненты. С точки зрения управления решением это походит на решение с 140 +, проекты являются подавляющими.
Мы всегда используем отдельный проект в том же решении.
Это означает, что мы можем быть уверены (использование ссылок), что код модульного теста также тестирует наши прямые ссылки (вместо того, чтобы неявно взять некоторую видимость чего-то, потому что это находится в том же блоке - например, "Внутреннее")
Обычно я помещал модульные тесты в их собственные и интеграционные тесты проекта в их собственном проекте в прикладном решении.
, Где я работаю, мы рассматриваем веб-тесты помещения в разном решении. Мы планируем совместно использовать веб-тестовую авторскую разработку с командой QA, и мы не хотим, чтобы эти тесты стали ответственностью сборки.
Я не использую.NET, но когда я разрабатываю тестовые сценарии любого вида, я сохраняю их изолированными от остальной части кода так, чтобы я мог развернуть приложение без тестов. Пользователь не нуждается или даже хочет тот материал.
Посмотрите на дизайн своего проекта. Если это где-нибудь близко к расположению MVC или одному из, его - альтернативы затем, у Вас должны быть отличные уровни различных блоков. Сделайте один тестовый компонент для каждого уровня Вашего дизайна.
Наш тестовый проект обычно работает вместо проекта, который создает EXE. Наш проект EXE является тонкой оболочкой, которая передает событие и информацию к блоку, заполненному классами контроллера, который имеет код большинство людей, помещенных в Проект EXE. Это позволяет Тестовому проекту симулировать быть EXE для 90% нормального процесса тестирования.
Мы все еще разрабатываем лучшее расположение относительно фактических тестовых сценариев. Прямо сейчас у нас есть несколько главных уровней нашей Утилиты платформы, Объектов Applicaiton, Платформы UI, Команд, Контроллеров UI и EXE. У нас есть один блок для каждого уровня за исключением EXE (который тестируется вручную). Когда мы редактируем блок, мы загружаем опытную сборку для того уровня. Когда мы должны сделать что-то, что касается каждого уровня, мы должны загрузить все опытные сборки.
Во время нашего одного процесса сборки кнопки мы выполняем тестовый проект exe. (У нас есть отдельная утилита для этого).