Tom>>Это как вообще? S>По той же ссылке
Странно, никогда такой проблемы не наблюдал. Возможно это связано с многопоточностью и студия пытается использовать все имеющиеся ядра.
S>>>Допустим, fixture использует некоторые общие данные для нескольких тестов. Генерить их перед каждым тестом — это сказывается на времени выполнения тестов. Складывать их в статические переменные? Это не нормально. Tom>>Почему это не нормально? Тоесть статические переменные — это не нормально, а один инстанс класса для нескольких тестов — это нормально? S>Один инстанс для нескольких тестов — это классика. Так работает все: NUnit, MbUnit, csUnit. лишь vsts отличилась.
Да бред это а не классика. Тесты должны быть изолированы и точка. Любое состояние класса является нарушением изоляции. Конечно за исключением специфических случаев. Другое дело что VS могла бы и иметь атрибуты позволяющие явно задавать настройки изоляции. Мне бы например для некоторых тестов хотелось бы использовать изоляцию на уровне домена.
S>Если бы методы одного теста работали вместе и сразу за ними производилась бы деинициализация fixture, то статические переменные были бы вполне ничего в этом случае. А в той ситуации, что есть — неизвестно когда наступит деинициализация потому статические переменные будут держать ссылки на данные неопределенное время. В программах, активно работающих с памятью это критично.
Ну так не храни в состоянии столько данных. Это же тесты, я не дцумаю что пару гигов в статических переменных тут нормально.
S>Допустим — требуется проверить работу алгоритма обработки снимка на реальных данных (большой снимок около 40Мб). Вчитывать его перед каждым тестов в методе SetUp (TestInitialize) не разумно. Хранить его в статической переменной — тоже, т.к. неизвестно, когда наступит FixtureTearDown/ClassCleanup или что-там. (да, это не совсем юнит тест, но можно считать это интеграционным тестом, исполненным в качестве юнит теста) S>Внятного сценария работы с такими тестовыми данными для vsts я не вижу.
Я думаю можно попытаться явно задавать порядок тестам, и в последнем освободить ресурсы. Можно использовать отдельную сборку и AssemblyCleanupAttribute. Можно приоритет прикрутить.
Здравствуйте, Tom, Вы писали:
Tom>>>Это как вообще? S>>По той же ссылке Tom>Странно, никогда такой проблемы не наблюдал. Возможно это связано с многопоточностью и студия пытается использовать все имеющиеся ядра.
Нет, тесты выполняются последовательно вне зависимости от кол-ва ядер. Студия грузит несколько доменов для выполнения тестов, но они все-равно последовательно отрабатывают.
S>>Один инстанс для нескольких тестов — это классика. Так работает все: NUnit, MbUnit, csUnit. лишь vsts отличилась. Tom>Да бред это а не классика. Тесты должны быть изолированы и точка. Любое состояние класса является нарушением изоляции. Конечно за исключением специфических случаев. Другое дело что VS могла бы и иметь атрибуты позволяющие явно задавать настройки изоляции. Мне бы например для некоторых тестов хотелось бы использовать изоляцию на уровне домена.
Тесты изолированы от тестовых данных?
S>>Если бы методы одного теста работали вместе и сразу за ними производилась бы деинициализация fixture, то статические переменные были бы вполне ничего в этом случае. А в той ситуации, что есть — неизвестно когда наступит деинициализация потому статические переменные будут держать ссылки на данные неопределенное время. В программах, активно работающих с памятью это критично. Tom>Ну так не храни в состоянии столько данных. Это же тесты, я не дцумаю что пару гигов в статических переменных тут нормально.
Не храни — это хорошо. Грузить/создавать данные перед каждым тестом?
S>>Допустим — требуется проверить работу алгоритма обработки снимка на реальных данных (большой снимок около 40Мб). Вчитывать его перед каждым тестов в методе SetUp (TestInitialize) не разумно. Хранить его в статической переменной — тоже, т.к. неизвестно, когда наступит FixtureTearDown/ClassCleanup или что-там. (да, это не совсем юнит тест, но можно считать это интеграционным тестом, исполненным в качестве юнит теста) S>>Внятного сценария работы с такими тестовыми данными для vsts я не вижу.
Tom>Я думаю можно попытаться явно задавать порядок тестам, и в последнем освободить ресурсы. Можно использовать отдельную сборку и AssemblyCleanupAttribute. Можно приоритет прикрутить.
Можно пытаться — это не решение на все случаи жизни. Плодить сборки на 5 тестов — тоже не выход.
А в NUnit просто нет таких проблем.
Здравствуйте, Nuseraro, Вы писали:
P>>>>Юнит-тесты — это глобальное зло. P>>Потому что стоимость разработки и поддержки этих юнит-тестов иногда даже больше, чем 50% стоимости проекта.
N>Во сколько % оцените стоимость тестирования и отладки ошибок в связи с изменениями в проектах без юнит-тестов и того же качества?
Здравствуйте, samius, Вы писали:
Tom>>>Что предлагается взамен?
P>>Полуручное тестирование (желательно большим числом людей). P>>Это простое, дешевое и надёжное средство.
S>Большое число людей это просто дешево и надежно?
Да. Это просто — нажать на кнопку и посмотреть на результат. Надёжность — 100%. Так как в данном случае мы исключаем ошибки самого юнит-тестирования и программы, осуществляющей юнит-тестирование.
Здравствуйте, Tom, Вы писали:
Tom>ЗЫ: Tom>Вообще у нас в проекте наибольшую эффективность показали именно интеграционные тесты. Когда код не пытаются изолировать, ну или изолируют но минимально. Tom>В юнит тестах я вообще не помню что бы мы нашли какие то баги а в интеграционных — постоянно.
Согласен. Именно на эту область и надо как-то налегать.
Однако, дальше будет только хуже. Потому что изменяется не только программный код определённой программы, но и среда окружения (выходят новые операционные системы, новые базы данных и т.д.).
Здравствуйте, ppvrt, Вы писали:
P>Здравствуйте, samius, Вы писали:
Tom>>>>Что предлагается взамен?
P>>>Полуручное тестирование (желательно большим числом людей). P>>>Это простое, дешевое и надёжное средство.
S>>Большое число людей это просто дешево и надежно? P>Да. Это просто — нажать на кнопку и посмотреть на результат. Надёжность — 100%.
И чего это народ мается? Автоматизированное тестирование не дает надежности 100%, а кнопка дает! Не все еще нашли эту кнопку
?
Да и будет ли такая экзотическая кнопка в конечном приложении?
P>Так как в данном случае мы исключаем ошибки самого юнит-тестирования и программы, осуществляющей юнит-тестирование.
Как-правило надо исключать ошибки в другом месте.
Здравствуйте, Ellin, Вы писали:
E>А вот еще скажите в плане юнит тестирования лучше NUnit или можно обойтись штатными средствами VS Team Edition? Я так смотрю даже EntLib написана с использованием NUnit. (хотя и недочетов там есть определенное колличество.... )
Мы вот пользуемся MSTest — никаких проблем не обнаружено... Главное для нас его преимущество — встроенность. Ну и к ccnet он подключился без проблем...
Здравствуйте, samius, Вы писали:
S>Не исключаю, что я не умею правильно готовить эту тулзу, но проблем от нее видал предостаточно.
Видимо таки не умеешь готовить
S>Во-первых, встроенная тулза ОЧЕНЬ долгая. На нескольких тысячах тестов разница заметна на глаз.
Есть такое дело, но это небольшая проблема, ибо все тесты прогоняются только на билд-сервере после билда, разработчик же обычно прогоняет только часть тестов...
S>Во-вторых, у встроенной тулзы большие проблемы с иерархиями тестов.
Не очень понимаю, зачем это может быть нужно, но имеется поддержка иерархических списков...
S>В-третьих, у встроенной тулзы возможен разный порядок выполнения тестов, оттого инициализация и деинициализация Fixture производится как-попало. Если в NUnit-е фактически есть гарантия того, что все тесты одного Fixture выполняются подряд между [FixtureSetUp] и [FixtureTearDown], то во встроенной тулзе между этими методами могут быть вызваны другие тесты от других Fixture. Фактически они гарантируют только то, что каждый тест выполнится между своими методами инициализации и деинициализации. Отсюда сложности с Arrange + Act + Assert подходом к тестированию; сложности с тем, чтобы скажем в методе инициализации FixtureSetUp открыть транзакцию, прогнать несколько тестов и потом в FixtureTearDown откатить транзакцию, потому как между открытием транзакции и закрытием могут попасть тесты из других классов, которые будут выполняться в своей транзакции. S>В четвертых, встроенная тулза не производит реюз класса для сценария с несколькими тестами. Для каждого теста класс теста создается заново. Это тоже приводит к некоторым проблемам. Для того, чтобы сохранить общее для нескольких тестов состояние, приходится использовать статические переменные. Время жизни таких переменных не определено, т.к. FixtureTearDown метод вызовется когда-нибудь, а не сразу по завершению всех тестов данного класса.
Не вполне понял, что имеется в виду, но может OrderedTest поможет...
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, samius, Вы писали:
S>>Не исключаю, что я не умею правильно готовить эту тулзу, но проблем от нее видал предостаточно. K>Видимо таки не умеешь готовить
Научи!
S>>Во-первых, встроенная тулза ОЧЕНЬ долгая. На нескольких тысячах тестов разница заметна на глаз. K>Есть такое дело, но это небольшая проблема, ибо все тесты прогоняются только на билд-сервере после билда, разработчик же обычно прогоняет только часть тестов...
Это проблема существенная, особенно после того как сравнишь как быстро прогоняется часть тестов NUnit-ом и как долго MSTest-ом. Просто хотя бы потому, что NUnit гонит их по месту, а MSTest копирует в TestResult каталог со всеми зависимостями, коих бывает много.
S>>Во-вторых, у встроенной тулзы большие проблемы с иерархиями тестов. K>Не очень понимаю, зачем это может быть нужно, но имеется поддержка иерархических списков...
Списки не решают проблемы запуска одного набора тестов для разных сущностей.
И вообще списки — отвратительная фича. Представь тысячу тестов в солюшне, они постоянно добавляются, удаляются, переименовываются и т.п. Кто будет раскладывать их по спискам и удалять из списков старые тесты? В системе контроля версий списки хранятся двоичным файлом — это вообще бред! Если более одного разработчика одновременно редактирует список, рождается такой нехилый конфликт, решать который иногда приходится через удаление списка. И еще эти списки регулярно дублируются в солюшне... Чем меньше трогаешь эти списки, тем меньше проблем.
S>>В-третьих, у встроенной тулзы возможен разный порядок выполнения тестов, оттого инициализация и деинициализация Fixture производится как-попало. Если в NUnit-е фактически есть гарантия того, что все тесты одного Fixture выполняются подряд между [FixtureSetUp] и [FixtureTearDown], то во встроенной тулзе между этими методами могут быть вызваны другие тесты от других Fixture. Фактически они гарантируют только то, что каждый тест выполнится между своими методами инициализации и деинициализации. Отсюда сложности с Arrange + Act + Assert подходом к тестированию; сложности с тем, чтобы скажем в методе инициализации FixtureSetUp открыть транзакцию, прогнать несколько тестов и потом в FixtureTearDown откатить транзакцию, потому как между открытием транзакции и закрытием могут попасть тесты из других классов, которые будут выполняться в своей транзакции. S>>В четвертых, встроенная тулза не производит реюз класса для сценария с несколькими тестами. Для каждого теста класс теста создается заново. Это тоже приводит к некоторым проблемам. Для того, чтобы сохранить общее для нескольких тестов состояние, приходится использовать статические переменные. Время жизни таких переменных не определено, т.к. FixtureTearDown метод вызовется когда-нибудь, а не сразу по завершению всех тестов данного класса.
K>Не вполне понял, что имеется в виду, но может OrderedTest поможет...
Имеется в виду вопрос размещения общего кода инициализации/деинициализации для тестов одного Fixture, так чтобы этот код не перемешивался с кодом инициализации/деинициализации тестов другого Fixture.
Боюсь, что OrderedTest не поможет, тем более что он не исключает запуска в нем расположенных тестов из общего списка.
Здравствуйте, samius, Вы писали:
S>Научи!
Ну попробую
S>Это проблема существенная, особенно после того как сравнишь как быстро прогоняется часть тестов NUnit-ом и как долго MSTest-ом. Просто хотя бы потому, что NUnit гонит их по месту, а MSTest копирует в TestResult каталог со всеми зависимостями, коих бывает много.
MSTest тоже умеет прогонять тесты "на месте", без копирования — соответствующая галочка имеется в настройках...
K>>Не очень понимаю, зачем это может быть нужно, но имеется поддержка иерархических списков... S>Списки не решают проблемы запуска одного набора тестов для разных сущностей. S>И вообще списки — отвратительная фича. Представь тысячу тестов в солюшне, они постоянно добавляются, удаляются, переименовываются и т.п. Кто будет раскладывать их по спискам и удалять из списков старые тесты? В системе контроля версий списки хранятся двоичным файлом — это вообще бред! Если более одного разработчика одновременно редактирует список, рождается такой нехилый конфликт, решать который иногда приходится через удаление списка. И еще эти списки регулярно дублируются в солюшне... Чем меньше трогаешь эти списки, тем меньше проблем.
Хз, может быть это и проблема, но лично я с ней не сталкивался Может быть дело в том, что у нас в команде мало разработчиков...
K>>Не вполне понял, что имеется в виду, но может OrderedTest поможет... S>Имеется в виду вопрос размещения общего кода инициализации/деинициализации для тестов одного Fixture, так чтобы этот код не перемешивался с кодом инициализации/деинициализации тестов другого Fixture. S>Боюсь, что OrderedTest не поможет, тем более что он не исключает запуска в нем расположенных тестов из общего списка.
У меня есть правило никогда не использовать Startup-teardown в юнит-тестах, а вместо этого всё необходимое делать в самом тесте (общий код инициализации конечно можно вынести в отдельные методы) , ибо по моему глубочайшему убеждению юнит-тест должен быть "вещью в себе" и ни коим образом не зависить от любых внешних условий (физических файлов, порядка выполнения) и не иметь никакого состояния. То, что вы говорите, может быть проблемой для интеграционных тестов, но их целесообразоно запускать только на билд-сервере — ибо они обычно выполняются долго, т.к. используют реальные БД/файлы/etc., а не их моки, как юнит-тесты...
В общем, тот подход, который я лично применяю, работает отлично на почти любом тест-фреймворке, ибо использует самый минимум его фич, но MSTest подкупает его встроенностью во все выпуски студии, начиная с Professional, а поскольку мне всё равно, то использовать какую-то внешнюю либу при наличии аналогичной встроенной считаю неразумным...
Опять же в ccnet это дело встало как влитое, благо готовые трансформации поставляются вместе с системой (ну разумеется я их немного допилил напильником под наши нужды, но изменений там самый минимум — буквально пара строчек).
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, samius, Вы писали:
S>>Научи! K>Ну попробую
S>>Это проблема существенная, особенно после того как сравнишь как быстро прогоняется часть тестов NUnit-ом и как долго MSTest-ом. Просто хотя бы потому, что NUnit гонит их по месту, а MSTest копирует в TestResult каталог со всеми зависимостями, коих бывает много. K>MSTest тоже умеет прогонять тесты "на месте", без копирования — соответствующая галочка имеется в настройках...
Не попадалась на глаза такая галочка.
K>>>Не очень понимаю, зачем это может быть нужно, но имеется поддержка иерархических списков... S>>Списки не решают проблемы запуска одного набора тестов для разных сущностей. S>>И вообще списки — отвратительная фича. Представь тысячу тестов в солюшне, они постоянно добавляются, удаляются, переименовываются и т.п. Кто будет раскладывать их по спискам и удалять из списков старые тесты? В системе контроля версий списки хранятся двоичным файлом — это вообще бред! Если более одного разработчика одновременно редактирует список, рождается такой нехилый конфликт, решать который иногда приходится через удаление списка. И еще эти списки регулярно дублируются в солюшне... Чем меньше трогаешь эти списки, тем меньше проблем. K>Хз, может быть это и проблема, но лично я с ней не сталкивался Может быть дело в том, что у нас в команде мало разработчиков...
У нас тоже мало разработчиков, но все равно предпочитаем эти списки не трогать. Разве что прибиваем лишние, когда они самопроизвольно размножаются.
K>У меня есть правило никогда не использовать Startup-teardown в юнит-тестах, а вместо этого всё необходимое делать в самом тесте (общий код инициализации конечно можно вынести в отдельные методы)
Вообще-то принято выносить инициализацию/деинициализацию в специальные методы SetUp/TearDown.
K>ибо по моему глубочайшему убеждению юнит-тест должен быть "вещью в себе" и ни коим образом не зависить от любых внешних условий (физических файлов, порядка выполнения) и не иметь никакого состояния.
Согласен, тем не менее, методы TestInitialize и TestCleanup в MSTest имеют слишком неопределенный порядок выполнения, чтобы ими вообще можно было пользоваться. Инициализацию и деинициализацию БД в них не положить, к сожалению.
K>То, что вы говорите, может быть проблемой для интеграционных тестов, но их целесообразоно запускать только на билд-сервере — ибо они обычно выполняются долго,
Это не означает, что не следует предпринимать попыток по ускорению запуска интеграционных тестов.
K>т.к. используют реальные БД/файлы/etc., а не их моки, как юнит-тесты...
Бывает что и юнит-тесты используют реальные БД. Например, юнит-тесты DAL. А бывают еще юнит-тесты мутаторов БД. Этим вообще перед каждым тестом нужна свежая копия БД с некоторой промежуточной схемой и тестовыми данными. Если не пытаться оптимизировать работу таких тестов, то это означает что каждый такой юнит-тест будет отрабатывать десятки секунд (а тестов сотни). Надеюсь, не надо объяснять, какой это дискомфорт при разработке?
K>В общем, тот подход, который я лично применяю, работает отлично на почти любом тест-фреймворке, ибо использует самый минимум его фич, но MSTest подкупает его встроенностью во все выпуски студии, начиная с Professional, а поскольку мне всё равно, то использовать какую-то внешнюю либу при наличии аналогичной встроенной считаю неразумным...
А мне не все равно. Того минимума, с которым MSTest работает без проблем, мне не хватает для комфортной повседневной работы.
K>Опять же в ccnet это дело встало как влитое, благо готовые трансформации поставляются вместе с системой (ну разумеется я их немного допилил напильником под наши нужды, но изменений там самый минимум — буквально пара строчек).
Полагаю, что c NUnit-ом у ccnet тоже все в порядке.
Здравствуйте, Tom, Вы писали:
Tom>Вообще у нас в проекте наибольшую эффективность показали именно интеграционные тесты. Когда код не пытаются изолировать, ну или изолируют но минимально. Tom>В юнит тестах я вообще не помню что бы мы нашли какие то баги а в интеграционных — постоянно.
Юнит тесты не ищут баги, у них другие задачи:
1. При использовании TDD понять, что требуется от класса и помочь задизайнить сам класс
2. Обеспечить управление требованиями к модулю который они тестируют, т.о. обезопасить дальнейшие рефакторинги системы.
Непонятно как может юнит тест найти ошибку, если он неотделим от написанного кода, т.е. комитится вместе с ним и комитится зеленым. Зато он отлично находит места, когда кто-то удалил "лишний" код и изменненый модуль престал корректно обрабатывать ошибку найденную 4 года назад и давно похороненную в багтрекере.
Здравствуйте, samius, Вы писали:
S>Не попадалась на глаза такая галочка.
Дабл-клик на *.testrunconfig -> Deployment -> Enable Deployment
S>Вообще-то принято выносить инициализацию/деинициализацию в специальные методы SetUp/TearDown.
А у меня вот не принято Может потому мне и хватает встроенного инструмента, а вам(тебе — хз как правильно) — нет
S>Согласен, тем не менее, методы TestInitialize и TestCleanup в MSTest имеют слишком неопределенный порядок выполнения, чтобы ими вообще можно было пользоваться. Инициализацию и деинициализацию БД в них не положить, к сожалению.
Для интеграционных тестов я использую создание БД с нуля из скриптов, а потом снос её по завершению. Поскольку тесты независимые, то всё проходит нормально. Может быть тут дело в том, как я пишу эти интеграционные тесты — например тест CRUD — это один тест у меня, выполняется самым первым, остальные тесты выполняются только при условии успешного выполнения CRUD, при необходимости используют CRUD-методы для создания необходимых сущностей в БД, а затем подчищают их, откатывая транзакцию либо используя внутри уже протестированные CRUD-методы.
S>Это не означает, что не следует предпринимать попыток по ускорению запуска интеграционных тестов.
Для меня лично это не проблема, потому что мне, если честно, всё равно, сколько они будут выполняться — у себя на машине разработчики их, как правило, не запускают...
S>Бывает что и юнит-тесты используют реальные БД. Например, юнит-тесты DAL. А бывают еще юнит-тесты мутаторов БД. Этим вообще перед каждым тестом нужна свежая копия БД с некоторой промежуточной схемой и тестовыми данными. Если не пытаться оптимизировать работу таких тестов, то это означает что каждый такой юнит-тест будет отрабатывать десятки секунд (а тестов сотни). Надеюсь, не надо объяснять, какой это дискомфорт при разработке?
У меня нет отдельных юнит-тестов DAL, он тестируется в составе интеграционных тестов...
S>А мне не все равно. Того минимума, с которым MSTest работает без проблем, мне не хватает для комфортной повседневной работы.
Каждому своё...
S>Полагаю, что c NUnit-ом у ccnet тоже все в порядке.
Совершенно верно.
Ещё использование встроенного фреймворка даёт мне некоторые нетехнические преимущества, но это уже тема отдельной беседы...
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, samius, Вы писали:
S>>Не попадалась на глаза такая галочка. K>Дабл-клик на *.testrunconfig -> Deployment -> Enable Deployment
---------------------------
Microsoft Visual Studio
---------------------------
The following error occurred:
Deployment must be enabled for the following: 1. Code Coverage
2. Remote Execution
3. Device Test Project
Please make sure there are no Device test projects, turn off Code Coverage and Remote Execution and try again.
The current operation will be aborted.
---------------------------
OK
---------------------------
S>>Вообще-то принято выносить инициализацию/деинициализацию в специальные методы SetUp/TearDown. K>А у меня вот не принято Может потому мне и хватает встроенного инструмента, а вам(тебе — хз как правильно) — нет
Не возражаю на "ты".
S>>Согласен, тем не менее, методы TestInitialize и TestCleanup в MSTest имеют слишком неопределенный порядок выполнения, чтобы ими вообще можно было пользоваться. Инициализацию и деинициализацию БД в них не положить, к сожалению. K>Для интеграционных тестов я использую создание БД с нуля из скриптов, а потом снос её по завершению. Поскольку тесты независимые, то всё проходит нормально. Может быть тут дело в том, как я пишу эти интеграционные тесты — например тест CRUD — это один тест у меня, выполняется самым первым, остальные тесты выполняются только при условии успешного выполнения CRUD, при необходимости используют CRUD-методы для создания необходимых сущностей в БД, а затем подчищают их, откатывая транзакцию либо используя внутри уже протестированные CRUD-методы.
Я тоже использую создание БД из скриптов. Вопрос в том, когда ее можно грохнуть, чтобы создать БД другой версии из скриптов, т.к. тестируются в том числе мутаторы.
Сейчас БД создается перед каждым тестом и удаляется после каждого теста. Не совсем так, но практически так. Вместо создания и удаления используется Attach/detach, но это все равно долго.
А вообще, не имею привычку делать checkin пока не удостоверюсь, что все тесты (например DAL) идут (чтобы скомпилировать и прогнать все интеграционные мне нужно минут 40), потому запускаю DAL тесты на своей машине. Если бы с самого начала использовал NUnit, то с созданием БД на несколько тестов не было бы проблем и все тесты пролетали бы мухой.
S>>Это не означает, что не следует предпринимать попыток по ускорению запуска интеграционных тестов. K>Для меня лично это не проблема, потому что мне, если честно, всё равно, сколько они будут выполняться — у себя на машине разработчики их, как правило, не запускают...
Ладно интеграционные, а юнит тесты того же DAL (у меня-то они есть и с невыполненными тестами DAL я не стану делать checkout, который требуется чтобы прогнать интеграционные).
S>>А мне не все равно. Того минимума, с которым MSTest работает без проблем, мне не хватает для комфортной повседневной работы. K>Каждому своё...
Точно. Имея под рукой инструмент, ограничивать себя в его использовании — это не для всех.
K>Ещё использование встроенного фреймворка даёт мне некоторые нетехнические преимущества, но это уже тема отдельной беседы...
психологические?
---------------------------
S>Microsoft Visual Studio
S>---------------------------
S>The following error occurred:
S>Deployment must be enabled for the following:
S> 1. Code Coverage
S> 2. Remote Execution
S> 3. Device Test Project
S>Please make sure there are no Device test projects, turn off Code Coverage and Remote Execution and try again.
S>The current operation will be aborted.
S>---------------------------
S>OK
S>---------------------------
Угу, но поскольку у меня стоит Professional, то покрытия нема всё равно =) Хотя и копированием честно говоря проблем особых не вижу, ибо время копирования исчезающе мало по сравнению с временем прогона тестов при более-менее плотном покрытии кода тестами...
S>Не возражаю на "ты".
Ок, принято.
S>Я тоже использую создание БД из скриптов. Вопрос в том, когда ее можно грохнуть, чтобы создать БД другой версии из скриптов, т.к. тестируются в том числе мутаторы. S>Сейчас БД создается перед каждым тестом и удаляется после каждого теста. Не совсем так, но практически так. Вместо создания и удаления используется Attach/detach, но это все равно долго.
Ну хз — у меня имеется пустая база, на которую я и накатываю скрипты при старте, и сношу все объекты по окончании. Работает конечно не слишком шустро, но вполне терпимо. Аттач/детач тоже пробовал, но уж очень медленно как-то оно...
S>А вообще, не имею привычку делать checkin пока не удостоверюсь, что все тесты (например DAL) идут (чтобы скомпилировать и прогнать все интеграционные мне нужно минут 40), потому запускаю DAL тесты на своей машине. Если бы с самого начала использовал NUnit, то с созданием БД на несколько тестов не было бы проблем и все тесты пролетали бы мухой.
Ну как я и сказал, интеграционные тесты я запускаю на своей машине только в случае серьёзного рефакторинга, когда время выполнения тестов не так важно, как уверенность, что ничего не поломано .
S>Ладно интеграционные, а юнит тесты того же DAL (у меня-то они есть и с невыполненными тестами DAL я не стану делать checkout, который требуется чтобы прогнать интеграционные).
Ну хз — я решил от тестов DAL отказаться, ибо необходимость их на нашем проекте весьма неочевидна ввиду того, что сама по себе БД изменяется довольно редко. Кстати изменение БД — это один из случаев, когда я прогоняю все тесты (в т.ч. интеграционные) у себя локально, ибо это тоже в принципе рефакторинг, и всё вышесказанное про него применимо и здесь.
S>Точно. Имея под рукой инструмент, ограничивать себя в его использовании — это не для всех.
В том-то и дело, что "под рукой" у меня MSTest , а nUnit ещё устанавливать надо...
S>психологические?
Нет, организационные. Дело в том, что мы часто отдаём части системы на аутсорсинг, и среди аутсорсеров попадаются товарищи с очень разной квалицикацией. Верите или нет, то иногда приходится объяснять человеку, как скомпилить приложение, если оно после взятия из SVN'а почему-то ругается на отсутствующие зависимости. С учётом этого вводить ещё одну в общем-то ненужную зависимость мы считаем неразумным...
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, samius, Вы писали:
S>>
S>>The following error occurred:
S>>Deployment must be enabled for the following:
S>> 1. Code Coverage
K>Угу, но поскольку у меня стоит Professional, то покрытия нема всё равно =) Хотя и копированием честно говоря проблем особых не вижу, ибо время копирования исчезающе мало по сравнению с временем прогона тестов при более-менее плотном покрытии кода тестами...
случалось до 20 секунд вместе с инструментированием под покрытие кода. Использую TestDriven.NET для быстрого запуска. Но он не всегда справляется. Deployment, например, игнорирует.
Кстати, о покрытии. Если бы его можно было включать/выключать одним кликом, то было бы проще. Чаще всего оно включено, потому подтормаживает выполнение тестов.
S>>Сейчас БД создается перед каждым тестом и удаляется после каждого теста. Не совсем так, но практически так. Вместо создания и удаления используется Attach/detach, но это все равно долго. K>Ну хз — у меня имеется пустая база, на которую я и накатываю скрипты при старте, и сношу все объекты по окончании. Работает конечно не слишком шустро, но вполне терпимо. Аттач/детач тоже пробовал, но уж очень медленно как-то оно...
В моем случае аттач много быстрее, чем создать БД со всеми таблицами, ключами и т.п.
K>Ну хз — я решил от тестов DAL отказаться, ибо необходимость их на нашем проекте весьма неочевидна ввиду того, что сама по себе БД изменяется довольно редко. Кстати изменение БД — это один из случаев, когда я прогоняю все тесты (в т.ч. интеграционные) у себя локально, ибо это тоже в принципе рефакторинг, и всё вышесказанное про него применимо и здесь.
А у нас БД переживает стадию бурного развития. К тому же, как это пошло ни звучит, закладываем возможность использования нескольких СУБД. Потому и актуально написание теста один раз и выполнения его для разных DAL реализаций.
S>>Точно. Имея под рукой инструмент, ограничивать себя в его использовании — это не для всех. K>В том-то и дело, что "под рукой" у меня MSTest , а nUnit ещё устанавливать надо...
Если бы его еще и ломать приходилось бы, то тогда конечно
S>>психологические? K>Нет, организационные. Дело в том, что мы часто отдаём части системы на аутсорсинг, и среди аутсорсеров попадаются товарищи с очень разной квалицикацией. Верите или нет, то иногда приходится объяснять человеку, как скомпилить приложение, если оно после взятия из SVN'а почему-то ругается на отсутствующие зависимости. С учётом этого вводить ещё одну в общем-то ненужную зависимость мы считаем неразумным...
У меня устойчивое ощущение что NUnit гораздо более широко распространен, чем MSTest, просто даже из-за своей доступности. И даже Microsoft NUnit-ом не брезгует. Статистики, конечно нет.
Еще один аргумент в пользу NUnit: он до сих пор развивается, обрастает удобными фичами и синтаксисом, атрибутами, констрейнтами, extension-ами... А MSTest фактически застрял в том виде, в котором был выпущен в 2005-м (уже тогда он уступал NUnit-у в плане возможностей). И даже косяки со списками не исправили к очередному выпуску студии.
Повелись вот на его встроенность, все не можем решиться перейти на NUnit (может потребоваться несколько дней для разруливания ситуаций, где не обойтись Search&Replace-ом).
S>Кстати, о покрытии. Если бы его можно было включать/выключать одним кликом, то было бы проще. Чаще всего оно включено, потому подтормаживает выполнение тестов.
Поставь Pro — и не будет никакого покрытия
S>В моем случае аттач много быстрее, чем создать БД со всеми таблицами, ключами и т.п.
S>А у нас БД переживает стадию бурного развития. К тому же, как это пошло ни звучит, закладываем возможность использования нескольких СУБД. Потому и актуально написание теста один раз и выполнения его для разных DAL реализаций.
Так это можно покрыть интеграционными тестами. Ибо по-любому сетап-тирдаун будет разным для разных БД, и тесты придётся пилить напильником под каждую конкретную БД
S>У меня устойчивое ощущение что NUnit гораздо более широко распространен, чем MSTest, просто даже из-за своей доступности. И даже Microsoft NUnit-ом не брезгует. Статистики, конечно нет.
Ну так уж выходит, что у нас в компании я являюсь основным евангелистом автоматического тестирования, потому остальные вообще не имеют своего мнения на тему nUnit vs MSTest А своё мнение я уже высказал.
S>Еще один аргумент в пользу NUnit: он до сих пор развивается, обрастает удобными фичами и синтаксисом, атрибутами, констрейнтами, extension-ами... А MSTest фактически застрял в том виде, в котором был выпущен в 2005-м (уже тогда он уступал NUnit-у в плане возможностей). И даже косяки со списками не исправили к очередному выпуску студии.
Ну то, как я использую тесты, позволяет пересесть на другой фреймворк почти без проблем, ибо базовый фукционал одинаковый
S>Повелись вот на его встроенность, все не можем решиться перейти на NUnit (может потребоваться несколько дней для разруливания ситуаций, где не обойтись Search&Replace-ом).
Значит, не очень-то и надо Было бы действительно надо — давно перешли бы. Или у вас тесты считаются чем-то необязательным, только отнимающим время?
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, samius, Вы писали:
S>>Кстати, о покрытии. Если бы его можно было включать/выключать одним кликом, то было бы проще. Чаще всего оно включено, потому подтормаживает выполнение тестов. K>Поставь Pro — и не будет никакого покрытия
Ну почему же, можно и NCover прикрутить бесплатную версию.
S>>А у нас БД переживает стадию бурного развития. К тому же, как это пошло ни звучит, закладываем возможность использования нескольких СУБД. Потому и актуально написание теста один раз и выполнения его для разных DAL реализаций. K>Так это можно покрыть интеграционными тестами. Ибо по-любому сетап-тирдаун будет разным для разных БД, и тесты придётся пилить напильником под каждую конкретную БД
В том-то и дело, что тесты одинаковые, а разные только инициализация движка. В NUnit-е это можно сделать прозрачно за счет наследования методов тестов, а в MSTest приходится копипастить методы тестов, т.к. он не подбирает методы из базового Fixture!
S>>Повелись вот на его встроенность, все не можем решиться перейти на NUnit (может потребоваться несколько дней для разруливания ситуаций, где не обойтись Search&Replace-ом). K>Значит, не очень-то и надо Было бы действительно надо — давно перешли бы. Или у вас тесты считаются чем-то необязательным, только отнимающим время?
Кое-кто в команде так считает, но основная причина — есть другие приоритеты.
Здравствуйте, samius, Вы писали:
S>В том-то и дело, что тесты одинаковые, а разные только инициализация движка. В NUnit-е это можно сделать прозрачно за счет наследования методов тестов, а в MSTest приходится копипастить методы тестов, т.к. он не подбирает методы из базового Fixture!
Если речь идет о TestInitialize-нутых методах, то MSTest все прекрасно "подбирает".
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, samius, Вы писали:
S>>В том-то и дело, что тесты одинаковые, а разные только инициализация движка. В NUnit-е это можно сделать прозрачно за счет наследования методов тестов, а в MSTest приходится копипастить методы тестов, т.к. он не подбирает методы из базового Fixture!
L>Если речь идет о TestInitialize-нутых методах, то MSTest все прекрасно "подбирает".
не совсем. Он не подбирает ClassInitialize методы из базового класса, определенном в другой сборке.
И мы автоматом получаем 2*{число производных классов} тестов. Потом просто дописываем BaseFixture::Test3 и Test3 умножается на число производных Fixture.
)
Может потому мне и хватает встроенного инструмента, а вам(тебе — хз как правильно) — нет 
