RECT/TODO

Материал из Etersoft wiki
Перейти к: навигация, поиск
Wackowiki-logo.png Blue Glass Arrow.svg MediaWiki logo.png
Эта страница была автоматически перемещена с old.wiki.etersoft.ru.
Эта страница наверняка требует чистки и улучшения — смело правьте разметку и ссылки.
Просьба по окончанию убрать этот шаблон со страницы.


RECT: что делать?

Опакечивание и использование третьими лицами

Важнейшая задача -- передавать тесты пользователям, чтобы можно было просто поставить пару пакетов и через 1 минуту запустить тесты, а затем получить результаты. Цель опакечивания -- упростить разворачивание тестовой среды.


Состояние: работа ведется


Бага в багзиле:
TBD


Подробности

На данный момент инфраструктура RECT не приспособленна для использования сторонними тестерами. Что же надо изменить?


Единственное, что реально должно требоваться от пользователя -- организовать и описать тестовую среду:

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


Последнее должно делаться в простом и понятном виде. Пока не ясно, стоит ли реально использовать YAML (или вернуться на json), но пример на YAML:

shares:

    server:

        address: //server/upload

    vista:

        address: //deimos/share

        description: Windows Vista



slaves:

    local:

        host: localhost

    local2:

        host: localhost

        port: 13555

    valhalla:

        host: valhalla

    deimos:

        host: deimos

        type: Linux

    deimosW:

        host: deimos

        type: Windows


Это не слишком, но всё-таки похоже на то, что есть.


Дальше, пользователь должен указать, какие тесты он хотел бы запускать, и на каких слейвах с какими шарами. Здесь следует учитывать, что

  • пользователи изначально не знают, какие тесты есть;
  • наборы тестов могут обновляться;
  • не стоит делать больших и непонятных конфигурационных файлов.


Это приводит нас к тому, что необходимо дополнительное средство -- стандартные наборы тестов (TestSuite):

  • вместе с пакетом должны идти несколько наборов, среди которых желательно иметь набор, включающий все тесты;
  • наборы вполне могут включаться в другие наборы;
  • один тест (метод TestCase) сам по себе является набором; класс-потомок TestCase является набором
  • пользователь должен иметь возможность создавать собственные наборы
  • TBD
    это далеко не всё


Пример набора:

basic:

    nshares: 1

    nslaves: 2

    tests:

       - ConnectivityTest

       - MountTest

            slaves: 1

       - MountTest

            slaves: 2

       - OneReadAnotherWrite


Такой набор может быть инстанцирован в пользовательском конфигурационном файле, в том числе несколько раз с разными параметрами.


run_basic:

    what: basic

    slaves: [ deimos ]

    share: [ server ]



run_basic_locally:

    what: basic

    slaves: [ local ]

    shares: [ server ]



Удобные отчёты

Самое главное в любом тестировании -- получить результат и воспользоваться им.

Для этого нужны красивые и удобные отчёты по результатам теста. Но в принципе

пользователю достаточно узнать прошёл тест или нет, и иметь возможность скинуть лог,

если произошла ошибка.


Состояние: странное


Бага в багзилле: кажется есть...


Подробности

Отчёты должны содержать:

  • подробное описание конфигурации;
  • подробное описание каждого теста;
  • результаты работы для каждого случая неудачи;
  • на самом видном месте -- сводные красивые таблицы.


Лично мне (IvanMelnikov) нравится оформление


http://beta.boost.org/development/tests/release/developer/test.html


Хотя нам лучше без frames и всё на одной страничке. Тогда обязательно:

  • каждая ячейка FAILED -- ссылка на то место, где можно посмотреть traceback
  • везде полно ссылок "вверх" на сводную таблицу.


На данный момент неплохо выглядят таблицы в Tests/Description. Это наводит на мысль, что экспортировать результаты теста в Wiki -- тоже удачная идея.



Промежуточный формат

Поддержка нескольких форматов очётов (html, wiki, текстовый...) означает, что одному проходу по набору тестов должно соответствовать несколько вызовов генераторов отчётов. Проще всего этого добиться, сохраняя отчёты в некий промежуточный формат (json? xml? yaml? peasty?) и реализовав генератор отчётов ввиде отдельных утилит. Также было бы неплохо, чтобы эти утилиты могли анализировать содержимое нескольких файлов/баз с результатами.


Вот (
пока неполный
) список данных, которые необходимо хранить:


  • Время и дата. Возможно, отдельно для начала и конца каждого теста.
  • Имя теста. На эту роль лучше всего подходит результат вызова TestCase.id().
  • Используемые шары. О шаре мы не можем (пока) сказать многое, а надо. Поэтому желаельно дать возможность в конфигурационном файле указать дополнительную информацию:
    • текстовый комментарий
    • возможно дополнительные поля с фиксированным набором значений (os, версию сервера, некоторые его существенные настройки, if any)
  • Используемые slaves
    • Сериализованый результат slave[n].sysinfo()
    • slave[n].description
    • версию RECT slave (
      необходимо добавить в sysinfo или сделать отдельный метод
      )
  • Результаты тестов. В случае ошибки:
    • Exception type (строка)
    • Exception value (строка?)
    • Traceback (строка).
Стоит посмотреть в сторону модуля traceback для преобразования этого дела в строки.
  • TBD


Для реализации необходимо разработать собственный вариант TextResult, который будет

  • в отличие от стандартного, сохранять и сведения об успешных запусках (достаточно 1 общий список вместо отдельных errors и failures)
  • сохранять время и дату
  • не смешивать информацию об исключениях
  • TBD



Полноценное тестовое покрытие

TBD
.


Планы на RECT2

Вмешательство rlz@ в процесс проектирования RECT оказалось на редкость продуктивным. Возникло несколько идей, которые, будучи реализованы, радикально изменят процесс разработки и использования тестов. Мне (IvanMelnikov) кажется, что такие перемены столь радикальны, что имеет смысл говорить о RECT2.


DSL

Предлагается придумать и реализовать Domain Specific Language (DSL) для описания тестов. Основная идея DSL по сравнению тестами на Python -- возможность манипулировать исходниками тестов программно. Это позволит генерировать разнообразные описания, а также исходные тексты на различных языках программирования.


Появится возможность:

  • найти все тесты, использующие определенные функции;
  • найти тест по краткому описанию;
  • генерировать автоматически описания ввиде flow diagrams или ввиде текста;
  • генерировать "минимальные программы для воспроизведения": программы на C, которые надо вручную запускать на целевых системах, чтобы воспроизвести проблему с минимальным количеством промежуточных "слоёв".


TODO
Предложения по синтаксису и всё такое.


Если не DSL

Без особых трудозатрат был получен полурабочий прототип, в котором тесты пишутся на Python. По разному реализуя основные функции и используя функцию exec можно выполнять эти тесты как для собственно запуска описаний, так и для многого другого. При желании можно использовать модуль питона ast, но такого желания пока нет.


Пример:


f = filename(exists=False)



file1 = S0.open(f, W, CREATE)

file1.lock()

file2 = S1.open(f, R)

fails(file2.lock)


Включение в отчёты

Уменьшение размеров и увеличение читаемости тестов позволит включить их текст в непосредственно в отчёт. Интересные дополнения:

  • разные представления (мы любим flow diagrams, как я их называю -- IvanMelnikov);
  • подсветка синтаксиса?


Требования к тестовой среде

Тест должен иметь возможность декларировать, какая тестовая среда ему нужна. На данный момент такие требования присутсвуют минимально (linux или windows-машина, число slave'ов).


Дополнительными требованиями к среде может быть наличие (или отсутствие) определенного файла. Для существующего файла могут быть заявлены специальные требования:

  • размер;
  • данные (конкретные, любые текстовые, нули, случайные);
  • локальные права доступа;
  • должен ли файл быть автоматически закрыт и/или удален после завершения теста (по умолчанию должен).


Идеальным вариантом было бы так же хотя бы частичное управление шарой (в случае Samba). Об этом ниже и позже.


Универсальные методы

Особенно это касается read и write. Стоит задуматься об упрощении написания тестов, имитирующих программы, "ведущие себя хорошо". Одна из простейших идей -- реализовать специальные версии read и write, которые на Linux будут перед осуществлением операции проверять, что всё впорядке с блокировками.


Асинхронные вызовы и блокирующие операции

Некоторые системные вызовы блокируют обратившийся к ним поток. Это тоже стоит тестировать. Подготовку тестовой среды для этого можно разделить на 2 части:

  • поддержку AMI в master;
  • поддержку остановки выполнения блокирующих операций в slave.


Тестирование потоков

Поведение в многопоточных и однопоточных приложениях может отличаться. Для полноты тестирования нужно рассматривать и многопоточные клиенты, что потребует многопоточных slave'ов. Это задача кажется не срочной и сложной.


Тестирование производительности

На данный момент RECT совершенно не пригоден для тестирования производительности.


TBD


Управление серверной частью

Необходимо как-то узнать, что за сервер использовался при тестировании. Однако информации, получаемой по протоколу CIFS, для этого не достаточно. Хотелось бы видеть следующую информацию:

  • О Windows:
    • версию системы
  • О Linux:
    • версию ядра
    • версию samba
    • опции сервера


Самый интересный вариант -- запускать на Linux samba с конкретными опциями. По запросу. Удаленно.


Второе, что требуется от сервера -- наличие/отсутсвие файлов. То есть, в рамках подготовки среды для конкретного теста, есть задачи:

  • создать файл
    • пустой
    • не пустой
      • с нулями
      • с конкретными данными
      • со случайными данными
      • конкретного размера
    • с конкретными правами доступа
  • получить имя файла, которого на шаре нет.


Возможно, удобно создать несложный сервис, запускаемый на сервере, и обеспечивающий всё это.