Предыдущая часть

Давайте за чем-нибудь следить! :-)

Пора приступить к реализации подсистем "тестового фреймворка моей мечты"!

Можно начать с довольно интересной подсистемы - Log viewer, которая может украсить любой фреймворк, но почему-то не украшает известные мне готовые решения.

Каждый хороший тестировщик описывает баги так, чтобы программисту легко было их повторить, понять причину их появления и исправить. Лучше всего для этого служит обычное описание шагов, которые приводят к ошибке в системе и лог, по которому программист определяет подсистему, модуль, класс и метод, который надо исправить. Чтобы экономить время программистов, надо прилагать лог системы к описанию бага. Но для этого надо самому повторить ситуацию, которая приводит к ошибке и скопировать серверный лог.

Давайте упростим эту процедуру - пусть логи сами записываются и нам не надо будет воспроизводить ситуацию. И, к тому же, сразу можем убить ещё одного зайца - будем присматривать за логом всегда, и, если там будут подозрительные записи (даже без ошибок на стороне клиента), лучше их проанализировать - "лучше заниматься профилактикой, а не лечением"!

Log viewer нужен для:

• слежения за:
  • лог файлами тестируемой системы,
  • файлами тестировочного окружения;
• в случае появления сообщения об ошибке - передать это в test framework (даже если тест прошёл без ошибок, наличие ошибок надо отслеживать);
• сохранить и выдать в test framework все сообщения, которые появились во время выполнения теста (эта информация может очень помочь во время анализа результатов непрошедшего теста).

Log viewer должен уметь:

• постоянно следить за лог файлом и оперативно реагировать на сообщения;
• работать одновременно с более чем одним лог файлом;
• иметь возможность указать директорию для того, чтобы следить за всеми вложенными лог файлами;
• обрабатывать ситуацию, когда лог файл изначально не нулевого размера;
• обрабатывать ситуацию, когда лог отсутствует;
• обрабатывать ситуацию, когда лог создаётся во время тест кейса;
• обрабатывать определённые уровни логов (ERROR, WARN, INFO, ...) и иметь возможность гибко настраивать анализатор сообщений;
• пропускать определённые записи для определённых тест кейсов (иногда проще указать это в конфигурации теста, чем убедить программистов изменить уровень записи в логе).

Как вы помните, мы решили начать делать тестовый фреймворк на Питоне как open source проект.

Вот и его реализация:

Диаграмма классов:

Эта архитектура выполнена в духе ООП, и удовлетворяет всем выше поставленным задачам и требованиям к подсистеме слежения за файлами. Надеюсь, что она получилась простая, понятная и удобная в использовании...

В общем, если это Вам интересно, то:

• смело используйте идею, реализацию (см. "источники");
• давайте идеи по улучшению, реализации и использованию;

Продолжение следует!