Я больше программист. Я только начал копаться глубоко в тестировании. Поэтому в данной статье больше программирования, чем тестирования. Я хотел раскрыть возможности .Net в данной области.
Вы правы. Это статья про еще один вариант использования частей .Net — Reflection и P\Invoke, и она направлена на разработчиков.
Имея под рукой пару таких сборок, разработчик может быстро набросать для себя несколько тестов на «родном» языке. Не каждый разработчик готов изучать дополнительный скриптовый язык. Не каждый знает, что за инструменты вообще есть.
Unit-тестирование это другое. Здесь мы эмулируем поведение пользователя, без доступа к коду (черный ящик).
Системы автоматизированного тестирования, такие как TestComplete ( www.automatedqa.com/products/testcomplete/ ) помогут сделать все то же самое и даже на порядок больше — и все без написания какого-либо кода вообще.
Велосипед велосипедом, а каждый из нас хотя бы раз в жизни, даже зная о том, что такое уже существует, все равно потратит день, неделю, месяц, чтобы попытаться сделать это самому — самоутвердиться что ли.
По-моему приятно, когда используешь средство и знаешь как оно работает.
На текущий момент уже нет ничего такого, чего бы не существовало, редко кто-то придумывает что-то кардинально новое, а вот предлагают более удобные, быстрые, легкие велосипеды ВСЕ.
Главное, чтобы колеса не были у него квадратные =)))
я вот чего не понимаю.
Использование рефлектора ведет тянет за собой причину отсутствия кода, значит они просто напросто недоступны тестировщику (нет надобности). Если есть такая сложность, значит есть причина (ы).
Хотя если очень хочется…
И еще советую посмотреть следующий софт — InqSoft Window Scanner.
Из основных фишек — Позволяет отправлять сообщения окнам, приятный интерфейс.
При использовании P\invoke рекомендуется сохранять сигнатуры. Мы используем несколько одноименных методов
Про рефлектор — показал, что отсутствие кода не слишком нам затрудняет задачу: все свойства и методы легко получить из сборки.
SendMessageN при очень похожих параметрах возможно делает методы чуть более различными, хотя наверное Вы правы — незачем такое городить.
Возможно было проще такое написать на Delphi/C++ etc. Но я не работал с этими языками. Но зато работаю с C#. Мне было интересно разобраться с таким вариантом использования данных механизмов.
А вы, случайно, не в курсе, что в VS 2010 есть нормальный встроенный механизм для тестирования UI?
Ну и особенно грустно, конечно, смотреть, как вы предлагаете тестировщику писать код (раз), занимаясь реверс-инжинирингом черного ящика (два). А то, что при следующей сборке разработчик поля переименует, вас не пугает? Или то, что поведение контрола при установке проперти и при вбивании в него текста руками может быть разным?
Автоматизация тестирования Windows-приложений с использованием .Net