Pull to refresh

Comments 17

Спасибо за труд, приложенный к написанию статьи, но…

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

… это самое главное в тестировании (я про результаты). Так что статья несет не очень много полезной практической(!) информации.
Я больше программист. Я только начал копаться глубоко в тестировании. Поэтому в данной статье больше программирования, чем тестирования. Я хотел раскрыть возможности .Net в данной области.
Я бы сказал, тут идет изобретение колеса.
UFO just landed and posted this here
Вы правы. Это статья про еще один вариант использования частей .Net — Reflection и P\Invoke, и она направлена на разработчиков.
Имея под рукой пару таких сборок, разработчик может быстро набросать для себя несколько тестов на «родном» языке. Не каждый разработчик готов изучать дополнительный скриптовый язык. Не каждый знает, что за инструменты вообще есть.

Unit-тестирование это другое. Здесь мы эмулируем поведение пользователя, без доступа к коду (черный ящик).
Unit-тестирование, в случае тестирования состояний (state-testing), тоже предполагает использование кода, как черного ящика.

Для чего нужно эмулировать действия пользователя? Конкретно для тестирования UI? Какой _именно_ кусочек логики нужно протестировать?

Для решения любых подобных задач действительно есть инструменты. Но умение пользоваться рефлектором не помешает, конечно :)
Системы автоматизированного тестирования, такие как TestComplete ( www.automatedqa.com/products/testcomplete/ ) помогут сделать все то же самое и даже на порядок больше — и все без написания какого-либо кода вообще.
Велосипед велосипедом, а каждый из нас хотя бы раз в жизни, даже зная о том, что такое уже существует, все равно потратит день, неделю, месяц, чтобы попытаться сделать это самому — самоутвердиться что ли.
По-моему приятно, когда используешь средство и знаешь как оно работает.

На текущий момент уже нет ничего такого, чего бы не существовало, редко кто-то придумывает что-то кардинально новое, а вот предлагают более удобные, быстрые, легкие велосипеды ВСЕ.
Главное, чтобы колеса не были у него квадратные =)))
Главное, чтобы работодатель про этот велосипед не пронюхал :)
UFO just landed and posted this here
я вот чего не понимаю.
Использование рефлектора ведет тянет за собой причину отсутствия кода, значит они просто напросто недоступны тестировщику (нет надобности). Если есть такая сложность, значит есть причина (ы).

Хотя если очень хочется…

И еще советую посмотреть следующий софт — InqSoft Window Scanner.
Из основных фишек — Позволяет отправлять сообщения окнам, приятный интерфейс.

И вот…
>>SendMessage1/2/3/n.

Зачем? оО
«ведет тянет» — тянет
«просто напросто» — просто-напросто
Ошибся, sorry.

[n] < — Уберите, имхо это с вики
При использовании P\invoke рекомендуется сохранять сигнатуры. Мы используем несколько одноименных методов

Про рефлектор — показал, что отсутствие кода не слишком нам затрудняет задачу: все свойства и методы легко получить из сборки.

SendMessageN при очень похожих параметрах возможно делает методы чуть более различными, хотя наверное Вы правы — незачем такое городить.

Возможно было проще такое написать на Delphi/C++ etc. Но я не работал с этими языками. Но зато работаю с C#. Мне было интересно разобраться с таким вариантом использования данных механизмов.
И еще:
1. .NET, донетом, но имхо проще было бы написать на Delphi/C++…
2. Почему ссылки на pinvoke.net нет в статье? ;)
А вы, случайно, не в курсе, что в VS 2010 есть нормальный встроенный механизм для тестирования UI?

Ну и особенно грустно, конечно, смотреть, как вы предлагаете тестировщику писать код (раз), занимаясь реверс-инжинирингом черного ящика (два). А то, что при следующей сборке разработчик поля переименует, вас не пугает? Или то, что поведение контрола при установке проперти и при вбивании в него текста руками может быть разным?
Sign up to leave a comment.

Articles