Если Модульные тесты находятся в своем собственном проекте в.Net Solution
Я должен запустить новый проект для своих модульных тестов? Это означало бы, что я получу два корректные исполняемых файла? Тогда я волнуюсь по поводу организации пространства имен. Я был бы в состоянии поместить модульный тест в те же пространства имен как классы, которые они тестируют, хотя они - часть другого проекта?
Это поднимает другой вопрос. Я знаю, что соглашением о присвоении имен пространства имен является CompanyName. TechnologyName. Feautre. Дизайн. Как я разобрался бы в этом в своем расположении решения/проекта? Название решения = companyname, название проекта = технологическое имя?
Если это так, делает это означает, что я не могу разделить свои модульные тесты на новый проект.
5 ответов
Наш массив объектов
var someData = [
{firstName: "Max", lastName: "Mustermann", age: 40},
{firstName: "Hagbard", lastName: "Celine", age: 44},
{firstName: "Karl", lastName: "Koch", age: 42},
];
с... в
var employees = {
accounting: []
};
for(var i in someData) {
var item = someData[i];
employees.accounting.push({
"firstName" : item.firstName,
"lastName" : item.lastName,
"age" : item.age
});
}
или с Array.prototype.map () , что намного чище:
var employees = {
accounting: []
};
someData.map(function(item) {
employees.accounting.push({
"firstName" : item.firstName,
"lastName" : item.lastName,
"age" : item.age
});
}
Как отмечено в другом ответе, любой контент, созданный или измененный JavaScript, вряд ли будет «виден» Хотя это, конечно, применимо везде, где вы размещаете JS.
В зависимости от размера страницы и возможностей хостинга она может повлиять на индексацию. Если дополнительная нагрузка достаточна для того, чтобы начать замедление ответа вашего сервера на запросы страниц, то поисковые системы замедлят их спайдеринг и для большого сайта могут не успеть своевременно пролезть весь сайт.
-121--2280201-Наилучший подход заключается в том, чтобы иметь отдельный проект модульных испытаний для «производственного проекта». Это гарантирует возможность изменения и перемещения их попарно.
Если имеется один проект модульного тестирования, охватывающий несколько целевых проектов, это создает искусственную плотную связь между этими двумя проектами, поскольку вы не сможете скомпилировать проект модульного тестирования без всех его целевых проектов. Это, опять же, делает действительно трудно протестировать один проект в изоляции - это то, о чем блок тестирование.
Очень важно хранить единичные тесты в отдельных библиотеках, поскольку это гарантирует, что вы протестируете только открытый API вашего кода (тестирование черного ящика).
Я называю свои пространства имен, добавляя UnitTest после целевого пространства имен.
У меня есть определенный тестовый проект / сборка для сборки. Тестовая сборка будет иметь то же имя, что и сборка, которую она должна тестировать, с добавлением .Test в имя и пространство имен.
Таким образом вы сохраните свои тесты изолированными, и они не будут развернуты вместе с вашим производственным кодом.
Возможно, можно создать хранимые процедуры для их удаления и создания. Хорошо ли это для вас?
-121--3266â-Ни одно из опубликованных решений не сработало для меня, поскольку мое приложение, управляемое AJAX, просто кэшировалось в последнем известном состоянии, прежде чем покинуть страницу (с автозаполнением = «off»), и когда пользователь использовал кнопку «back», браузер правильно не вставил предыдущее значение в поле поиска (так как набор автозаполнение атрибута было отключаем). Таким образом, единственным решением в этом случае было запустить мой JS, и для этого я должен был предотвратить кэширование. Я нашел этот простой фрагмент, чтобы хорошо работать. Просто вставьте его на главную страницу (то, что пользователь будет уходить при нажатии на любую из ссылок), и вы должны предотвратить кэширование довольно хорошо. Затем используйте JS для заполнения всех требуемых значений, включая значение поля автозавершения.
window.onbeforeunload = function () {
// Empty function, but it prevents the browser caching this anyway!
}
1 тестовый проект для каждого решения с папками = > регрессия/интеграция/единица, которая имеет подпапки, «зеркально отражающие» архитектуру проекта/папки решения.
Помните - тесты не являются вашим производственным кодом. Они должны быть разделены.
Да. Создайте проект модульного тестирования для каждого проекта решения.
Будет только один исполняемый файл. Модульные тесты хранятся в DLL.
Почему бы не добавить « UnitTests » в соответствующее пространство имен.
Да. Ваши модульные тесты должны быть отдельным проектом, который компилируется в свою собственную DLL.
Это означает, что вы не развертываете тестовый код вместе со своим проектом - и это способствует хорошему дизайну (поскольку ваши тесты не могут видеть частные / внутренние свойства, вы, естественно, склонны тестировать те части вашего проекта, которые взаимодействуют с другие системы, вместо того, чтобы зацикливаться на тестировании каждой детали их внутренней реализации)
Что касается именования, мы обычно выбираем «кодовое имя» для каждого проекта - текущий называется Занзибар - а затем заканчиваем такими проектами, как:
MyCompany.Zanzibar.Website (веб-приложение ASP.NET MVC)
MyCompany.Zanzibar.Website.Testing (содержит модульные тесты для веб-приложения MVC)