Comments 23
В личном блоге пост никто не увидит — перенесите хотя бы в .NET
А выбор фрейморков для тестирования не ограничивается VSTS и xUnit. Есть отличный MbUnit + Galio, xUnit.net и др.
А выбор фрейморков для тестирования не ограничивается VSTS и xUnit. Есть отличный MbUnit + Galio, xUnit.net и др.
А вот статья про автоматизацию тестирования в Silverlight была бы значительно короче. :(
UFO just landed and posted this here
Потому что с ним все плохо.
SilverUnit
cthru.codeplex.com/
cthru.codeplex.com/
Вот этой штукой можно запускать на билд сервере — statlight.net/. Тестируем сильверлайт во-всю, никаких проблем нет =)
Работа с БД это не модульные тесты, а скорее интеграционные. Если вы используете их в живом проекте, то сколько «модульных» тестов у вас уже есть?
Если у вас их накопится порядка 500, то как часто вы их запускаете?
Вообще впервые вижу, чтобы SQL командами писали «модульные» тесты. Как на счет рефакторинга этих тестов и их поддержки?
Если у вас их накопится порядка 500, то как часто вы их запускаете?
Вообще впервые вижу, чтобы SQL командами писали «модульные» тесты. Как на счет рефакторинга этих тестов и их поддержки?
Модульные тесты базы — имеется в виду тестирование именно функционала нашей бд, будь-то тригерры, хранимые процедуры или что-то еще. И часто запускать их тоже не требуется, ведь в основном изменения в базу вносятся реже, чем в остальные части программы.
Если не сложно, пару ваших комментариев на три моих вопроса.
В проекте, на основе которого писались тесты, в базе существует 15 хранимых процедур. Итого, 15 тестов БД. Запускается довольно быстро, но так как теперь база уже существует и проверена тестами — время на тесты БД в общее время тестирования программы не добавляется.
Если около 500, там уже надо разбивать тесты на группы выполнения и в зависимости от внесенных изменений в базу, выполнять конкретные группы. Хотя такой же вопрос можно задать и при тестировании кода — что делать с порядка 500 тестами?
Насчет SQL команд: если мы тестируем последовательность SQL команда(хранимки или триггеры) то логично на том же тесты писать. Поправьте, если я не прав.
Если около 500, там уже надо разбивать тесты на группы выполнения и в зависимости от внесенных изменений в базу, выполнять конкретные группы. Хотя такой же вопрос можно задать и при тестировании кода — что делать с порядка 500 тестами?
Насчет SQL команд: если мы тестируем последовательность SQL команда(хранимки или триггеры) то логично на том же тесты писать. Поправьте, если я не прав.
Хотя такой же вопрос можно задать и при тестировании кода — что делать с порядка 500 тестами?
У нас в проектах >1000 модульных тестов — это нормально. Они не зависят от внешних ресурсов, поэтому проходят меньше чем за минуту.
надо разбивать тесты на группы выполнения и в зависимости от внесенных изменений в базу, выполнять конкретные группы
Ты можешь получить гораздо больше, если на любое изменение системы сможешь разом прогнать все тесты. Изменения иногда могут затронуть очень неожиданные части системы.
Хотя такой же вопрос можно задать и при тестировании кода — что делать с порядка 500 тестами?
У нас в проектах >1000 модульных тестов — это нормально. Они не зависят от внешних ресурсов, поэтому проходят меньше чем за минуту.
Но работу базы все равно придется проверить и потому придется смириться с не очень быстрым (по сравнению с кодом) выполнением тестов.
Прошлый комментарий случайно не туда написал и продублировал сверху.
Да, но мне кажется работу с БД стоит проверять в интеграционных тестах, когда мы имитируем действия пользователя и можем тестировать данные в БД.
В твоем способе меня смущает поддержка этих тестов. Код выглядит не понятно, возможно следует сделать рефакторинг, возможно это удел тестирования SQL запросов.
Да, но мне кажется работу с БД стоит проверять в интеграционных тестах, когда мы имитируем действия пользователя и можем тестировать данные в БД.
В твоем способе меня смущает поддержка этих тестов. Код выглядит не понятно, возможно следует сделать рефакторинг, возможно это удел тестирования SQL запросов.
Может быть. Но в таком случае мы вдобавок становимся зависимыми от именно кода (контроллера и модели) если я правильно понимаю?
Как раз этот код нам не нужен. Приведу пример. Ваш тестовый метод GetUserIdByName не вещь в себе. Он создан для того, чтобы участвовать в какой-то пользовательской истории. Например, вход на сайт.
Берем Selenium и воспроизводим вход пользователя на сайт, при этом добавляя пользователя в тестовую БД перед тестом. Напрямую мы не трогаем код бизнес логики, а тестируем сразу все части системы, включая метод GetUserIdByName.
Такие тесты проходят тоже не быстро, но здесь взаимодействие с БД привязано к пользовательской истории. Поддерживать такие тесты удобно, потому что они отражают бизнес-требования.
Берем Selenium и воспроизводим вход пользователя на сайт, при этом добавляя пользователя в тестовую БД перед тестом. Напрямую мы не трогаем код бизнес логики, а тестируем сразу все части системы, включая метод GetUserIdByName.
Такие тесты проходят тоже не быстро, но здесь взаимодействие с БД привязано к пользовательской истории. Поддерживать такие тесты удобно, потому что они отражают бизнес-требования.
Да, возможно.
Вообще, это уже вопрос удобства и того, кто будет писать тесты во время активной разработки. Ведь проверить одну процедуру быстрее и легче, чем отдельный бизнес-процесс приложения.
А вот уже при финальном тестировании, без интеграционных тестов будет хуже. Необходима уже полная проверка каких-то юзкейсов приложения.
Но для меня эта область достаточно новая, так что не буду сильно спорить.
Вообще, это уже вопрос удобства и того, кто будет писать тесты во время активной разработки. Ведь проверить одну процедуру быстрее и легче, чем отдельный бизнес-процесс приложения.
А вот уже при финальном тестировании, без интеграционных тестов будет хуже. Необходима уже полная проверка каких-то юзкейсов приложения.
Но для меня эта область достаточно новая, так что не буду сильно спорить.
Есть мнение, что база должна тестироваться отдельно (желательно в самой базе).
Это связано с тем, что модульные тесты должны проходить максимально быстро.
А данные для тестирования бизнес-логики браться из mock-объектов.
Для проверки работы с БД достаточно проверять что вызывается нужна ХП с нужным списком параметров (опять же с помощью mock-объектов)
Это связано с тем, что модульные тесты должны проходить максимально быстро.
А данные для тестирования бизнес-логики браться из mock-объектов.
Для проверки работы с БД достаточно проверять что вызывается нужна ХП с нужным списком параметров (опять же с помощью mock-объектов)
Sign up to leave a comment.
Unit-тестирование средствами .NET