Спецификация важно - это утверждение ясно всем. Широко используется продукт, технология или язык без спецификации не имеет смысла. Спецификации без TestSuite опасно. TestSuite без разметки и тестов невозможно. Этот процесс является довольно сложным. Однако Есть способы, чтобы упростить разметки этапе.
Что касается спецификации языка программирования Java (JLS) и (Виртуальных машин), они написаны в FrameMaker. После спецификации экспортируются в HTML и PDF. Разметки встраивается в HTML-версии. Мое мнение, что разметку информации должны быть помещены в (или связанные с ними) происхождения текста. В нашем случае это FrameMaker документа. Я не уверен, что это вообще возможно, но я думаю это. Если нет, то, может быть, FrameMaker не лучшее решение. В результате мы значительно уменьшить количество времени и усилий, необходимых для передачи старой разметки и маркировки до нового текста. Кроме того во время записи следующего пересмотра спектра автором совместно с TCK команда должна разметки все поменявшее и новые утверждения. Я бы сказал, лучше всего, когда спектр письменной форме и разметки процессы выполняются одновременно. Целесообразно для автора указывают на то, что разработчики тест отчетность должна быть проверена.
Соответствие разработке тестов включает в себя определение утверждения в спецификации, писать тесты на совместимость, что проверка определила утверждения и связи тест на утверждение, что испытания. Давайте исходить из следующих пунктов: - Утверждение характеризуется - Фактическое утверждение трудно увидеть в спектре (в настоящее время Есть только небольшие GIF утверждение в конце каждого утверждения) - Полное утверждения только рассматривать, читая, прямо или HTML глядя друг на испытания отдельных - Начало утверждения трудно увидеть в HTML код - Обеспечение визуальной способ просмотра утверждение легко это проблема, которую мы пытаемся решить.
Главное, чтобы цвет утверждения (спецификации самого текста) с помощью HTML-тегов. Исследование было проведено которые HTML теги для использования. Div, пролет, стол и шрифт тегов смотреть. Наилучшим решением является тэгов для шрифтов. Так текст окружен шрифта метки. Класса атрибут тега шрифта соответствует типу утверждения. Fe, если asserion нового она окрашена красным, показывают, что тесты должны быть написаны, старое утверждение окрашены зеленым чтобы указать, что испытания уже существуют. Там должна быть утилита (скрипт или Java-программы) для проверки размеченные спецификации и автоматически добавлять теги, необходимых для раскраски. Фоновый цвет текста будет определяться по цвету названия атрибута утверждение. Этот метод был реализован, и работает отлично. Для удобства целях, не должно быть механизм, чтобы скрыть цвет, Fe JavaScript.
Недостатком такого решения является то, что цвет является статической, поскольку она основана на название атрибута. Второго решения будет то, что инструмент будет проверить на существование испытаний (на основе идентификатора утверждение или ссылку на утверждение). Если тест существует, мы хотели бы сделать что-то установить цвет этого утверждения. Это может быть также просто, как установление название атрибута. Недостаток этого решения будет то, что утверждение окраски бы еще статичны, а на основе, когда пользователь запускать скрипты.
Вариации на данное решение, что мы будем динамически генерировать охвата данных, когда спектр просматривается в браузере. Мы хотели бы определить, является ли тест существует в тестовый каталог для данного утверждения и цвет утверждение соответственно. Это можно сделать через JavaScript / VBScript, используя объекты, которые позволяют доступ к файловой системе. Этот метод будет динамичным и должны всегда иметь последнюю информацию о положении утверждение охвата.
Вот некоторые примеры из JLS3 главы "преобразование и акции" и "Интерфейс":
conv063 Утверждения, conv047, conv065, conv48, conv66 и conv049 взяты из предыдущей версии спецификации, они не изменили и тесты обновления не требуется - цвет аквамарина (neurtal зеленый). Conv155 conv156 и новые, новые тесты должны быть разработаны, утверждения окрашены в яркий красный цвет. Conv064 был изменен, проверьте обновление необходимо - оранжевого цвета. Annot019 является новым, тесты существуют, но они необходимо изменить - лосось цвета. Annot020 является новым, но кудумфте испытаний существует - цвет светло-зеленый.
Главное преимущество спектр окраски является то, что спецификации визуализируется. Пользователь может видеть весь утверждение и его название. Можно сказать, глядя на спецификации, где Есть районы с низким уровнем охвата, где некоторые или много испытаний должны быть добавлены или изменены. Существует в основном возможность увидеть, насколько хорошо спецификации размечена, и насколько хорошо оно проходит испытание.
Это очень важно иметь хороший процесс при написании тестов. Я буду говорить о том, что 1 был использован для JLS.
Как уже упоминалось выше конечный продукт ряд испытаний. Существует связь между испытаниями и спецификации. Утверждение внутренних ресурсов дает представление о том, что каждая группа тестов на самом деле проверки в спецификации. Используя это соотношение разработчик может рассчитывать охвата, получить список утверждений, на которых испытания не были написаны и т.д.
Утверждение это заявление от спецификации, которая может быть проверена. И первым шагом является определение всех утверждений в спецификации. После этого разработчик может написать тесты.
Ошибка во время компиляции происходит, если же модификатор, выглядит более чем один раз в объявлении интерфейса.
Бинарных имя члена типа состоит из бинарных имя его сразу вмещающих типа, а затем $, после чего простое имя члена.
Продолжать заявление может происходить только в то время, делать, или заявление.
Там может быть много заявлений, которые не являются проверяемыми или включать неопределенности. Иногда такие заявления включать такие слова, как "возможно" или "возможно". Это неправда, что если предложение имеет слово "может" не проверяемого, но обычно это так.
Пример не-проверяемым заявления:
Мы не рекомендуем такой "смешанных обозначения" для массивов.
Ситуации, когда класс объекта не известны статически может привести к ошибки времени выполнения типа.
Если, однако, оценка выражение генерирует исключение, то выражение называется полной круто.
Есть много дискуссий и споров о утверждений. Некоторые говорят, что примеры не должны рассматриваться как утверждения. Другие говорят, что каждый оператор и утверждения Есть два вида из них: проверяемые и не проверяемые. Мое личное мнение таково, что утверждение, безусловно, то проверяемым. И в большинстве случаев примеры утверждения только потому, что испытания могут быть записаны проверки конкретного примера.
Процесс выявления утверждения в спецификации называется разметки. Есть много подходов. Но в любом случае пользователь должен иметь возможность получить информацию о том, утверждение утверждение и как-то отличать один от другого утверждения. Там может быть отдельное хранилище с отображением утверждений и их идентификаторов для отчетности. Мне нравится идея интеграции разметки в спецификацию. Этот подход был выбран для языка области Java SE тестов. JLS была написана в FrameMaker. С механизмы экспорта PDF и HTML версии были созданы. HTML-версия была использована при создании тестового набора.
В JLS JLS и 2 специальных якорей определены в начале и в конце утверждение. Дополнительная информация была assertionID и краткое резюме в заявлении. Конец якорь изображение и ссылку на тест. HTML Посмотреть и код вид приведены на соответствующих рисунках. Утверждение ID являются arr033, arr034, arr020 и т.д.
Общая идея может быть описана как:
<a name=assertionID> <! - Шорд описание в виде HTML-комментарий -> утверждение выступлении здесь <img src="pics/assert.gif"> href="path <a к test"> тест ID который так же, как утверждение ID </ A>
Если отдельные заявления в различных частях спецификации проверяются один тест первый тэг будет что-то вроде arr033_0, arr033_1, arr033_2.
Такая архитектура была использована для JLS и JLS 2. Она была немного модифицирована для JLS3, но основная идея была сохранена. Я знаю несколько примеров подходов нестатических утверждение идентификаторы хранятся в отдельном хранилище, где ID некоторая хэш-значение, вычисленное на основе содержания. По ряду причин он показал, чтобы быть не очень хорошим решением. Существует всегда сложный процесс перехода на новую версию спецификации. Но, на мой взгляд, это гораздо проще с помощью статического удостоверения личности вкладывается в спецификации.
Спецификация важно - это утверждение ясно всем. Широко используется продукт, технология или язык без спецификации не имеет смысла. Спецификации без TestSuite опасно. TestSuite без разметки и тестов невозможно. Этот процесс является довольно сложным. Однако Есть способы, чтобы упростить разметки этапе. 
