четверг, 14 июня 2012 г.

Lesson 126

Возможно, я потом оформлю пост на софтваре-тестинг, но ответьте сейчас.
Те, кто кто использует webdriver, сколько RAM у вас ест тестирующая система (если параллелите, то на каждый поток)?

У меня каждый поток:
firefox: 200m физической, 700m виртуальной.
Собственно ТС: 100m физической, 300m виртуальной

Использовал столбцы RES и VIRT команды top


Слово Канеру

Не создавайте тестовые библиотеки только для того, чтоб избежать повторения кода.


Стандартная мудрость программистов рекомендует избегать повторения кода с помощью размещения кода в функциях, которые вызываются из каждого места, где был повторяющийся код. В автоматизации такой подход часто приводит к проблемам. Противоположный подход, который оставляет код на месте, называется открытым кодированием.

По своей природе тесты содержат много повторений. Вы тестируете одну фичу в разных сценариях, в разном порядке или в комбинации с другими фичами.

Если вы просто переместите повторяющийся код, вы получите мешанину в библиотеках и функции, содержащие последовательности задач, следующих друг за другом, даже если они являются частями различных задач. Соглашения по именованию, анализ результатов, стратегия тестирования также могут оказаться в беспорядке. Функции сложно называть осмысленно, а в связи с этим сложно делать выводы о их назначении.
Тесты, использующие такие библиотеки, сложно просматривать, сложно отлаживать и сложно чинить. Мы просматривали тестовые наборы с мешаниной из библиотек несколько раз. Результаты никогда не были хорошими.
Автоматизация тестирования влечет за собой много повторяющегося кода. Полезные библиотеки требуют более строгих принципов проектирования, чем простое избегание повторяющегося кода. Задача полезной библиотеки состоит в инкапсуляции пользовательских задач, уделяя особое внимание начальному и конечному состоянию функции. Но и этот подход не всегда оправдан. В таких случаях следует придерживаться стандартов открытого кодирования.

Комментариев нет:

Отправить комментарий