Утверждение окраски

rainbow Assertion coloring Соответствие разработке тестов включает в себя определение утверждения в спецификации, писать тесты на совместимость, что проверка определила утверждения и связи тест на утверждение, что испытания.
Давайте исходить из следующих пунктов:
- Утверждение характеризуется
- Фактическое утверждение трудно увидеть в спектре (в настоящее время Есть только небольшие GIF утверждение в конце каждого утверждения)
- Полное утверждения только рассматривать, читая, прямо или HTML глядя друг на испытания отдельных
- Начало утверждения трудно увидеть в HTML код
- Обеспечение визуальной способ просмотра утверждение легко это проблема, которую мы пытаемся решить.

Главное, чтобы цвет утверждения (спецификации самого текста) с помощью HTML-тегов. Исследование было проведено которые HTML теги для использования. Div, пролет, стол и шрифт тегов смотреть. Наилучшим решением является тэгов для шрифтов. Так текст окружен шрифта метки. Класса атрибут тега шрифта соответствует типу утверждения. Fe, если asserion нового она окрашена красным, показывают, что тесты должны быть написаны, старое утверждение окрашены зеленым чтобы указать, что испытания уже существуют. Там должна быть утилита (скрипт или Java-программы) для проверки размеченные спецификации и автоматически добавлять теги, необходимых для раскраски. Фоновый цвет текста будет определяться по цвету названия атрибута утверждение. Этот метод был реализован, и работает отлично. Для удобства целях, не должно быть механизм, чтобы скрыть цвет, Fe JavaScript.

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

Вариации на данное решение, что мы будем динамически генерировать охвата данных, когда спектр просматривается в браузере. Мы хотели бы определить, является ли тест существует в тестовый каталог для данного утверждения и цвет утверждение соответственно. Это можно сделать через JavaScript / VBScript, используя объекты, которые позволяют доступ к файловой системе. Этот метод будет динамичным и должны всегда иметь последнюю информацию о положении утверждение охвата.

Вот некоторые примеры из JLS3 главы "преобразование и акции" и "Интерфейс":

JLS3 colored Assertion coloring

JLS3 colored2 Assertion coloring

conv063 Утверждения, conv047, conv065, conv48, conv66 и conv049 взяты из предыдущей версии спецификации, они не изменили и тесты обновления не требуется - цвет аквамарина (neurtal зеленый). Conv155 conv156 и новые, новые тесты должны быть разработаны, утверждения окрашены в яркий красный цвет. Conv064 был изменен, проверьте обновление необходимо - оранжевого цвета. Annot019 является новым, тесты существуют, но они необходимо изменить - лосось цвета. Annot020 является новым, но кудумфте испытаний существует - цвет светло-зеленый.

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



, , , , , , ,
  • Закладки
Print This Post Распечатать этот пост

Разметки метаданных

11 Markup metadata Простейшее определение метаданных, что это данные о данных. Метаданные могут быть очень полезны. Что касается разметки, существуют определенные метаданные встроенных: ID, небольшое описание утверждение, ссылка на тест. В разметки передачи я понял, что больше метаданных бы очень полезно. В новой версии спецификации существует несколько видов утверждений:

  • возраста:
    без измененный текст, тесты не нужны изменения;
  • oldToBeChanged:
    текст изменен, тесты должны быть изменены;
  • новое:
    суммарно новый текст, новые испытания необходимы;
  • newWritten:
    Новый текст, но испытания уже существует (потому что процесс развития испытания начались, как только проект был доступен спектр);
  • newWrittenToBeChanged:
    Новый текст, тесты существуют, проект спектра изменить таким образом, испытания должны быть изменены или существующие тесты недостаточно.

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

С данной разметки архитектуры это было решено использовать название атрибута HREF-теги (второй якорь). Так разметки будет выглядеть так:

<a name=assertionID> <! - Шорд описание в виде HTML-комментарий ->
утверждение выступлении здесь
<img src="pics/assert.gif"> href="path <a к test" title=assertType> тест ID который так же, как утверждение ID </ A>

Название атрибута можно просматривать в браузере, как намек.

JLS3 html Markup metadata

JLS3 html code Markup metadata



, , , , , , , , , ,
  • Закладки
Print This Post Распечатать этот пост

Разметки перевода - кошмар или кусочек торта?

train Markup transfer   nightmare or a piece of cake?
Весь процесс создания разметки и развивающихся испытаний времени. И когда кажется, что работа сделана, новая версия спецификации освобождены. Что происходит дальше? Конечно, есть необходимость в новой версии тестового пакета. Новые тесты должны быть написаны, а старые обновлены или даже исключить.

Самый лучший способ начать это делать разметку. Эта задача может быть разделена на две подзадачи:

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

Перенос разметки является достаточно простым, чтобы сделать это вручную:

  1. Найти теги разметки в старой спецификации.
  2. Найти лучшее место для вставки тегов в новой версии спецификации.
  3. Включить метку.

Если Есть только 10 утверждений - это работа кусок пирога. Но если Существуют тысячи это тяжелый труд, который должен быть автоматизирован. Самая трудная часть, чтобы найти новых правильное место для разметки тегов. Трудно только потому, что спектр был изменен. Для JLS2 JLS3 в процессе миграции flollowing alrorithm были использованы:

Каждое утверждение округляется с HTML якорей. Оба они должны быть переданы с использованием таких алгоритмов.

Хин 1T: если некоторые теги передается, есть большая вероятность того, что следующий тег в старых спектра будут размещены после 1, которая передается.

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

  1. Посмотрите на текст перед и после тега в старой спецификации. Найти ее в новой спецификации. Если один из них 72s Markup transfer   nightmare or a piece of cake? не изменилась - ответ найден. Обычно длина должна быть на 1-2 sentances, по крайней мере 60 символов. Если ни один или несколько sentances найдено - пропустить этот шаг.
  2. Попробуйте сделать то же самое, как в (1), но удалить все HTML-теги к тексту, который окружает метки. Если никто не нашел - пропустить этот шаг.
  3. Попробуйте принять алгоритм, который пытается найти подобный текст в новой спецификации.
    . Используйте действия (1) и (2), но desrease длина поиска текста в цикле, пока Сентанс находится или длина является слишком коротким. Практической работы показал, что это число не должно быть меньше 20.
    б. Если шаги (1) и (2), или (3, a) нашел несколько sentances увеличить длину текстового поиска, пока текст не находится в спектре новых или верхний предел (напр. 140 символов) будет достигнут. Использовать подсказки, чтобы найти наиболее подходящий текст.

Принять алгоритм может использоваться как с игнорируя HTML-теги и воспользоваться ими. Алгоритм подходит для спецификации написаны в виде простого текста, HTML или XML.

Этот алгоритм был реализован в JLS2-> JLS3 инструмент передачи разметки. 84% от разметки метки были переведены автоматически. Остальные были сделаны вручную.



, , , , , ,
  • Закладки
Print This Post Распечатать этот пост