Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 7
Жаль не подходит для тестирования казуальных игрушек.
Почему не подходит? Тот же Coded UI вполне справится с игрушками. Классами Mouse/Keyboard из Microsoft.VisualStudio.TestTools.UITesting можно кликать и печатать. Через ApplicationUnderTest — снимать скриншоты, и по ним делать Assert-ы. Автоматизировать можно тестирование чего угодно, вопрос лишь в окупаемости.
«десКтопных» приложений, прошу прощения
На данный момент мы не используем автоматизации тестирования гуев, но если такая необходимость встанет, то только Coded UI Test.
Во первых — не нужно объяснять каждому разработчику, зачем писать полотенце тестов в дополнение к программе (Вы рассмотрели простейший случай, а гуя могут быть достаточно сложным, да как правило так оно и есть).
Во вторых — это действительно не надо писать. Экономим время.
В третьих — каждый программист делает 1 ошибку в 10 строках кода и это нормально. Следовательно, если расписать тестирование, то нужно потом это отдебажить. Банальности в виде опечаток и прочего первоитерационного хлама уйдут тут же. А как быть с неявными?
В четвертых — при вариации тестов — переписывание заново.
Тестирование должно помогать. Если нужно потратить день, чтобы написать тест к окну, то лучше оттестировать вручную — там и вариативности хоть отбавляй, и тестировщики тоже люди — тыкают куда не попадя и пишут что не попадя, так что есть шанс отловить ошибку ввода данных.
Во первых — не нужно объяснять каждому разработчику, зачем писать полотенце тестов в дополнение к программе (Вы рассмотрели простейший случай, а гуя могут быть достаточно сложным, да как правило так оно и есть).
Во вторых — это действительно не надо писать. Экономим время.
В третьих — каждый программист делает 1 ошибку в 10 строках кода и это нормально. Следовательно, если расписать тестирование, то нужно потом это отдебажить. Банальности в виде опечаток и прочего первоитерационного хлама уйдут тут же. А как быть с неявными?
В четвертых — при вариации тестов — переписывание заново.
Тестирование должно помогать. Если нужно потратить день, чтобы написать тест к окну, то лучше оттестировать вручную — там и вариативности хоть отбавляй, и тестировщики тоже люди — тыкают куда не попадя и пишут что не попадя, так что есть шанс отловить ошибку ввода данных.
но если такая необходимость встанет, то только Coded UI Test.
Ну если со стоимостью проблем нет, то выбор действительно неплохой.
не нужно объяснять каждому разработчику, зачем писать полотенце тестов в дополнение к программе.Не очень понял этот момент. А проблем с объяснением зачем писать модульные тесты не возникает?
вы рассмотрели простейший случай, а гуя могут быть достаточно сложным, да как правило так оно и естьНу простой пример был выбран для удобства демонстрации тестов. В реальной жизни я занимался автоматизацией тестирования UI достаточно сложной системы(что-то типа CADa) и могу сказать, что главное проблемы начинается на тестировании граничных условий. Например вам нужно проверить попап, который возникает при отсутствии свободного места на диске. Как вы будет делать на это автоматический тест силами только Code UI?
это действительно не надо писать. Экономим время.Безусловно, поэтому я и отметил рекорде как плюс.
каждый программист делает 1 ошибку в 10 строках кода и это нормально.Вообще вы как-то утрировали. Ошибки часто делают при описании логики. Делать уровня выполнения при написании 10 ассертов — ну это надо быть талантом. А от опечаток и прочего хорошо защищает статический анализ того же решашрпера. Вообще же речь шла о командах, которые уже используют TDD, пишут регрешен тесты и т.д. Для такие команд написание еще и тестов для UI не стане шоустопером.
при вариации тестов — переписывание заново.Ну изменение продакшен кода конечно может привести к необходимости поменять тесты. Но это абсолютно логично для все автоматического регрешен тестирования вообще. И code ui вас тут не спасет — я удалил часть кнопок, поменять часть контролов, значит надо перезаписать тесты.
Если нужно потратить день, чтобы написать тест к окну, то лучше оттестировать вручнуюНет не лучше, т.к. потом после каждой итерации надо будет снова потратить день на ручное тестирования этого окна. Не знаю какой опыт у вас, а я не однократно встречался с ситуацией, когда на одной итерации ломали функционал, сделанный на предыдущих.
тыкают куда не попадя и пишут что не попадя, так что есть шанс отловить ошибку ввода данныхАвтоматизированное тестирование не противопоставляется ручному, а дополняет его. Чтобы те же тестеры не проходили одни и теже тесткейсы по 100 раз.
Извиняюсь, промахнулся с кнопкой. Еще раз с нормальным форматированием.
Ну если со стоимостью проблем нет, то выбор действительно неплохой.
Не очень понял этот момент. А проблем с объяснением зачем писать модульные тесты не возникает?
Ну простой пример был выбран для удобства демонстрации тестов. В реальной жизни я занимался автоматизацией тестирования UI достаточно сложной системы(что-то типа CADa) и могу сказать, что главное проблемы начинается на тестировании граничных условий. Например вам нужно проверить попап, который возникает при отсутствии свободного места на диске. Как вы будет делать на это автоматический тест силами только Code UI?
Безусловно, поэтому я и отметил рекорде как плюс.
Вообще вы как-то утрировали. Ошибки часто делают при описании логики. Делать уровня выполнения при написании 10 ассертов — ну это надо быть талантом. А от опечаток и прочего хорошо защищает статический анализ того же решашрпера. Вообще же речь шла о командах, которые уже используют TDD, пишут регрешен тесты и т.д. Для такие команд написание еще и тестов для UI не стане шоустопером.
Ну изменение продакшен кода конечно может привести к необходимости поменять тесты. Но это абсолютно логично для всего автоматического регрешен тестирования вообще. И code ui вас тут не спасет — я удалил часть кнопок, поменять часть контролов, значит надо перезаписать тесты.
Нет не лучше, т.к. потом после каждой итерации надо будет снова потратить день на ручное тестирования этого окна. Не знаю какой опыт у вас, а я не однократно встречался с ситуацией, когда на одной итерации ломали функционал, сделанный на предыдущих.
Автоматизированное тестирование не противопоставляется ручному, а дополняет его. Чтобы те же тестеры не проходили одни и теже тесткейсы по 100 раз.
но если такая необходимость встанет, то только Coded UI Test.
Ну если со стоимостью проблем нет, то выбор действительно неплохой.
не нужно объяснять каждому разработчику, зачем писать полотенце тестов в дополнение к программе.
Не очень понял этот момент. А проблем с объяснением зачем писать модульные тесты не возникает?
вы рассмотрели простейший случай, а гуя могут быть достаточно сложным, да как правило так оно и есть
Ну простой пример был выбран для удобства демонстрации тестов. В реальной жизни я занимался автоматизацией тестирования UI достаточно сложной системы(что-то типа CADa) и могу сказать, что главное проблемы начинается на тестировании граничных условий. Например вам нужно проверить попап, который возникает при отсутствии свободного места на диске. Как вы будет делать на это автоматический тест силами только Code UI?
это действительно не надо писать. Экономим время.
Безусловно, поэтому я и отметил рекорде как плюс.
каждый программист делает 1 ошибку в 10 строках кода и это нормально.
Вообще вы как-то утрировали. Ошибки часто делают при описании логики. Делать уровня выполнения при написании 10 ассертов — ну это надо быть талантом. А от опечаток и прочего хорошо защищает статический анализ того же решашрпера. Вообще же речь шла о командах, которые уже используют TDD, пишут регрешен тесты и т.д. Для такие команд написание еще и тестов для UI не стане шоустопером.
при вариации тестов — переписывание заново.
Ну изменение продакшен кода конечно может привести к необходимости поменять тесты. Но это абсолютно логично для всего автоматического регрешен тестирования вообще. И code ui вас тут не спасет — я удалил часть кнопок, поменять часть контролов, значит надо перезаписать тесты.
Если нужно потратить день, чтобы написать тест к окну, то лучше оттестировать вручную
Нет не лучше, т.к. потом после каждой итерации надо будет снова потратить день на ручное тестирования этого окна. Не знаю какой опыт у вас, а я не однократно встречался с ситуацией, когда на одной итерации ломали функционал, сделанный на предыдущих.
тыкают куда не попадя и пишут что не попадя, так что есть шанс отловить ошибку ввода данных
Автоматизированное тестирование не противопоставляется ручному, а дополняет его. Чтобы те же тестеры не проходили одни и теже тесткейсы по 100 раз.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Написание автоматических тестов для тестирования пользовательского интерфейса десктопных приложений