модульные тесты на анализ экранных данных?
Точка инверсии зависимости должна сделать допускающее повторное использование программное обеспечение.
идея состоит в том, что вместо двух частей кода, полагающегося друг на друга, они полагаются на некоторый абстрактный интерфейс. Тогда можно снова использовать любую часть без другого.
способ, которым это обычно достигается, через контейнер инверсии управления (IoC) как Spring в Java. В этой модели свойства объектов настраиваются через конфигурацию XML вместо объектов, выходящих и находящих их зависимость.
Воображают этот псевдокод...
public class MyClass
{
public Service myService = ServiceLocator.service;
}
MyClass непосредственно зависит и от Класса обслуживания и от класса ServiceLocator. Этому нужны оба из тех, если Вы хотите использовать его в другом приложении. Теперь вообразите это...
public class MyClass
{
public IService myService;
}
Теперь, MyClass полагается на единственный интерфейс, интерфейс IService. Мы позволили контейнеру МОК на самом деле установить значение той переменной.
Поэтому теперь, MyClass может легко быть снова использован в других проектах, не принося зависимость тех других двух классов наряду с ним.
Еще лучше, Вы не должны перетаскивать зависимости MyService и зависимости тех зависимостей, и... хорошо, Вы получаете идею.
3 ответа
Модульное тестирование всегда должно разрабатываться так, чтобы иметь повторяемые известные результаты.
Следовательно, чтобы выполнить модульное тестирование скребка экрана, вы должны написать тест для известного набора HTML (вы можете использовать фиктивный объект для представления этого)
То, о чем вы говорите, не для меня это действительно похоже на сценарий для модульного тестирования - если вы хотите, чтобы ваш код работал как можно более надежно, тогда это больше, как вы говорите, о тестировании в коде и обработке исключений.
Я бы также включил некоторый код предупреждения, поэтому они сообщают вам обо всех случаях, когда HTML не анализируется должным образом.
Вам следует попытаться разделить ваши тесты как можно больше. Протестируйте обработку данных с помощью низкоуровневых тестов, которые выполняют реальный код (т.е. , а не через смоделированный браузер).
В смоделированном браузере просто убедитесь, что при нажатии на кнопки происходят правильные действия, когда вы отправляете формы и переходите по ссылкам.
Никогда не пытайтесь проверить правильность макета.
Я думаю, что здесь могут быть полезны модульные тесты, если у вас есть сервер сборки, они дадут вам раннее предупреждение, что код больше не работает. Вы не можете написать модульный тест, чтобы доказать, что сканирование экрана по-прежнему будет работать, если сайт изменит свой HTML (потому что вы не можете сказать, что они изменят).
Вы можете написать модульный тест, чтобы проверить, что что-то полезное возвращается из ваших усилий.