BDD и UI Тестирование - PullRequest
       8

BDD и UI Тестирование

1 голос
/ 18 января 2011

Вот вопрос ...

У нас есть приложение WPF MVVM, использующее IronRuby. Мы используем док-менеджер DevExpress. У нас есть тесты на огурец (заставить его работать на IronRuby был лидером нашей команды с помощью dolorosa)

Часть наших требований позволяет пользователю сохранять макет своего экрана. Какой хороший способ обернуть BDD тесты вокруг этого?

Макет сохраняется, когда пользователь закрывает приложение.

Вот моя первая идея.

  1. Пусть огурец откроет приложение.
  2. Пусть огурец использует bewildr и / или белый цвет для перемещения. (Сложно смоделировать пользователя, перемещающего макет.)
  3. Сделайте скриншот или еще что-нибудь.
  4. Закройте приложение.
  5. Снова откройте приложение.
  6. Сделайте скриншот или еще что-нибудь.
  7. Сравните скриншоты или что-то

Видите, хотя это сработает, я думаю, что это запутанный способ добиться цели. Я надеялся, что кто-то здесь может дать мне предложение о том, что может быть «чем-то» на вышеуказанных шагах.

Ответы [ 2 ]

0 голосов
/ 27 января 2011

Элементы Bewildr будут иметь методы 'width' и 'height', доступные в следующем выпуске (через несколько дней - код проверен и работает). Я думаю, вы могли бы использовать их, чтобы получить размер элемента, чтобы увидеть, остается ли он одинаковым при перезапуске приложения. Вы также можете использовать метод clickable_point, чтобы определить, перемещается ли щелкающая точка элемента (обычно центральная точка) при перезапуске приложения - немного странно, но это сработает ...

0 голосов
/ 19 января 2011

Белый основан на UI Automation, и если он не поддерживает стыковку и ограничивающие прямоугольники, вы всегда можете покопаться в шаблонах UI Automation и использовать их. Попробуйте использовать DockingPattern и BoundingRectangleProperty на интересующих вас панелях. Это должно позволить вам записать, где они находятся и как минимум их размер.

Также помните, что вам не нужно писать автоматические сценарии для всего . Эстетичность и удобство использования часто лучше проверять вручную, поскольку они не приносят пользы, если пользователям они не нравятся, независимо от того, во что верят автоматизированные тесты. Сценарии существуют для обеспечения общего понимания - посредством разговоров, которые они ведут, - и для облегчения изменений - путем предоставления документации и системы безопасности. Если вы никогда не собираетесь менять свой механизм закрепления (потому что это стороннее приложение), просто протестируйте его вручную и оставьте в покое.

...