Unit-тестирование средствами .NET

[alek_sys]

В личном блоге пост никто не увидит — перенесите хотя бы в .NET

А выбор фрейморков для тестирования не ограничивается VSTS и xUnit. Есть отличный MbUnit + Galio, xUnit.net и др.

[Sirix]

Кармы не было, теперь перенес, спасибо.
Насчет фреймворков — просто спросил, каким пользуются знакомые программисты.

[EaE]

А вот статья про автоматизацию тестирования в Silverlight была бы значительно короче. :(

[EaE]

Потому что с ним все плохо.

[ulu]

SilverUnit
cthru.codeplex.com/

[EaE]

Я посмотрю обязательно. Сейчас уже не могу вспомнить, чем конкретно этот фреймворк нам не подошел, но у всех из них были свои ограничения в той или иной области. Но я попробую и напишу обязательно, что получилось. Спасибо.

[EaE]

А, ну, из банального:

[EaE]

Does SilverUnit support Silverlight 3.0?

Not officially. It has not been tested with it yet. There is a very high chance that tests already written against silverlight 2.0 should just work if the code under test is compiled into Silverlight 3.0.

[tearaway_Tea]

Вот этой штукой можно запускать на билд сервере — statlight.net/. Тестируем сильверлайт во-всю, никаких проблем нет =)

[AlexanderByndyu]

Работа с БД это не модульные тесты, а скорее интеграционные. Если вы используете их в живом проекте, то сколько «модульных» тестов у вас уже есть?
Если у вас их накопится порядка 500, то как часто вы их запускаете?

Вообще впервые вижу, чтобы SQL командами писали «модульные» тесты. Как на счет рефакторинга этих тестов и их поддержки?

[Sirix]

Модульные тесты базы — имеется в виду тестирование именно функционала нашей бд, будь-то тригерры, хранимые процедуры или что-то еще. И часто запускать их тоже не требуется, ведь в основном изменения в базу вносятся реже, чем в остальные части программы.

[AlexanderByndyu]

Если не сложно, пару ваших комментариев на три моих вопроса.

[Sirix]

В проекте, на основе которого писались тесты, в базе существует 15 хранимых процедур. Итого, 15 тестов БД. Запускается довольно быстро, но так как теперь база уже существует и проверена тестами — время на тесты БД в общее время тестирования программы не добавляется.

Если около 500, там уже надо разбивать тесты на группы выполнения и в зависимости от внесенных изменений в базу, выполнять конкретные группы. Хотя такой же вопрос можно задать и при тестировании кода — что делать с порядка 500 тестами?

Насчет SQL команд: если мы тестируем последовательность SQL команда(хранимки или триггеры) то логично на том же тесты писать. Поправьте, если я не прав.

[AlexanderByndyu]

Хотя такой же вопрос можно задать и при тестировании кода — что делать с порядка 500 тестами?

У нас в проектах >1000 модульных тестов — это нормально. Они не зависят от внешних ресурсов, поэтому проходят меньше чем за минуту.

надо разбивать тесты на группы выполнения и в зависимости от внесенных изменений в базу, выполнять конкретные группы

Ты можешь получить гораздо больше, если на любое изменение системы сможешь разом прогнать все тесты. Изменения иногда могут затронуть очень неожиданные части системы.

[AlexanderByndyu]

Хотя такой же вопрос можно задать и при тестировании кода — что делать с порядка 500 тестами?

У нас в проектах >1000 модульных тестов — это нормально. Они не зависят от внешних ресурсов, поэтому проходят меньше чем за минуту.

[Sirix]

Но работу базы все равно придется проверить и потому придется смириться с не очень быстрым (по сравнению с кодом) выполнением тестов.

[AlexanderByndyu]

Прошлый комментарий случайно не туда написал и продублировал сверху.

Да, но мне кажется работу с БД стоит проверять в интеграционных тестах, когда мы имитируем действия пользователя и можем тестировать данные в БД.

В твоем способе меня смущает поддержка этих тестов. Код выглядит не понятно, возможно следует сделать рефакторинг, возможно это удел тестирования SQL запросов.

[Sirix]

Может быть. Но в таком случае мы вдобавок становимся зависимыми от именно кода (контроллера и модели) если я правильно понимаю?

[AlexanderByndyu]

Как раз этот код нам не нужен. Приведу пример. Ваш тестовый метод GetUserIdByName не вещь в себе. Он создан для того, чтобы участвовать в какой-то пользовательской истории. Например, вход на сайт.

Берем Selenium и воспроизводим вход пользователя на сайт, при этом добавляя пользователя в тестовую БД перед тестом. Напрямую мы не трогаем код бизнес логики, а тестируем сразу все части системы, включая метод GetUserIdByName.

Такие тесты проходят тоже не быстро, но здесь взаимодействие с БД привязано к пользовательской истории. Поддерживать такие тесты удобно, потому что они отражают бизнес-требования.

[Sirix]

Да, возможно.
Вообще, это уже вопрос удобства и того, кто будет писать тесты во время активной разработки. Ведь проверить одну процедуру быстрее и легче, чем отдельный бизнес-процесс приложения.

А вот уже при финальном тестировании, без интеграционных тестов будет хуже. Необходима уже полная проверка каких-то юзкейсов приложения.

Но для меня эта область достаточно новая, так что не буду сильно спорить.

[AlexanderByndyu]

Ясно. Я тоже вначале писал модульные тесты, которые зависят от БД, поэтому мне было интересно, как это у вас получилось.

Проблемы с этими тестами очевидные: трудно поддерживать и долго прогонять.

[Denom]

Есть мнение, что база должна тестироваться отдельно (желательно в самой базе).
Это связано с тем, что модульные тесты должны проходить максимально быстро.
А данные для тестирования бизнес-логики браться из mock-объектов.
Для проверки работы с БД достаточно проверять что вызывается нужна ХП с нужным списком параметров (опять же с помощью mock-объектов)