Комплект Тестирования Совместимости Java (TCK): Обзор и Значение

Введение

Комплект совместимости технологий (TCK) — это набор тестов, который как минимум формально проверяет соответствие конкретной заявленной реализации запроса спецификации Java (JSR). Это один из трех обязательных компонентов для утвержденного JSR в рамках Java Community Process, а именно: спецификация JSR, эталонная реализация JSR и комплект совместимости технологий (TCK).

Содержание и архитектура

ТКК обычно получают у ведущего разработчика спецификации данного JSR. Они обычно (но не всегда) состоят из графического хост-приложения, которое взаимодействует по протоколу TCP/IP с тестируемым устройством или виртуальной машиной Java. Устройство обычно получает тесты по протоколу HTTP, а результаты отправляет обратно в хост-приложение аналогичным образом. Такая независимость позволяет использовать ТКК для тестирования виртуальных машин на устройствах, таких как мобильные телефоны CLDC, которые не обладают достаточной вычислительной мощностью для запуска полноценного хост-приложения ТКК. Тесты, содержащиеся в JSR, предположительно, основаны на положениях спецификации JSR. Для каждого API предусмотрен набор тестов, чтобы убедиться в его корректной работе, включая обработку ошибок. Чтобы подтвердить соответствие JSR, реализация Java должна успешно пройти соответствующий ТКК. Любые (редкие) исключения должны быть согласованы с ведущим разработчиком спецификации. В связи с этим ТКК играют важную роль при реализации JSR. Первым важным этапом является запуск ТКК, что требует определенной степени зрелости как реализации Java, так и базового сетевого стека. Затем ТКК необходимо правильно настроить, поскольку они должны быть достаточно гибкими для работы с любой реализацией и имеют множество опций. (Например, перечисление всех поддерживаемых форматов мультимедиа и связанных с ними необязательных элементов управления для JSR135). Некоторые тесты также требуют предварительной настройки, что особенно сложно для тестов, проверяющих корректную обработку ошибок, поскольку реализацию Java необходимо привести в определенное состояние для возникновения каждой ошибки. Наконец, необходимо исправить каждый проваленный тест, что обычно осуществляется с помощью стандартных механизмов отслеживания дефектов. Некоторые разработчики Java считают свой продукт практически завершенным после успешного прохождения ТКК. Хотя ТКК действительно достаточно всесторонние, они не охватывают многие аспекты, такие как производительность и необязательные функции. Единственный способ устранить эти недостатки – это проведение обширного реального тестирования, хотя дополнительные наборы тестов, такие как JDTS, могут оказаться полезными.

TCKs tend to be obtained from the Specification Lead of a given JSR. They usually (but not always) consist of a graphical host application which communicates over TCP/IP with the device or Java virtual machine that is under test. Tests are typically obtained by the device over HTTP, and results are posted back to the host application in a similar way. This decoupling enables TCKs to be used to test virtual machines on devices such as CLDC mobile phones which do not have the power to run the full TCK host application. The tests contained in the JSR are supposedly derived from the statements in the JSR specification. Any given API will have a set of tests to ensure that it behaves in the intended way, including in error conditions. In order to state conformance with a given JSR, a Java implementation has to pass the associated TCK. Any (rare) exceptions have to be negotiated with the specification lead. Because of this, TCKs are of great importance when implementing a JSR. The first great milestone is to get the TCK running in the first place, which necessarily involves the Java implementation and underlying networking stack having a certain level of maturity. Next, the TCK must be properly configured because they must be flexible enough to cope with any implementation, there are many options. (For example, listing all the supported media formats and associated optional controls for JSR135). Particular tests also require some setup activity this tends to be particularly complex for the tests which ensure correct behaviour in error conditions, because the Java implementation must be put in the right state to cause each error. Finally, each failing test must be fixed, which is usually handled by the usual defect tracking mechanisms. Some Java implementors consider their product to be mainly complete once the TCKs pass. Whilst it's true that the TCKs are quite comprehensive, there are many areas that they do not cover. These include performance, as well as the optional features. There's no alternative but to do much real world testing to address these shortcomings, although additional test suites such as JDTS may help.

TCK для платформы Java

Комплект совместимости технологий для конкретной платформы Java называется Java Compatibility Kit (JCK). Это обширный набор тестов, используемый Oracle и лицензиатами для обеспечения совместимости реализаций платформы. JCK для исходного кода Java 6.0 был выпущен. Изначально сопутствующая лицензия не разрешала пользователям компилировать или запускать тесты, однако право на просмотр кода не связано с рисками компрометации, и публичные комментарии к исходному коду допускаются. Лицензионное соглашение OpenJDK Community TCK v 2.0 было опубликовано для спецификации Java SE 7 начиная с декабря 2011 года.

Рамочная система ТКК

Инструмент JavaTest harness на сегодняшний день является наиболее распространенной системой модульного тестирования, используемой для проверки соответствия реализации. Это универсальная система тестирования, разработанная для запуска тестов TCK. Однако некоторые спецификации также используют JUnit или TestNG.

Лицензия и споры

После выпуска OpenJDK компанией Sun, Sun выпустила специальную лицензию, разрешающую запуск TCK в контексте OpenJDK для любой реализации, распространяемой по лицензии GPL и существенно основанной на OpenJDK. Это условие лишает проект Apache Harmony права использовать TCK, совместимого с лицензией Apache. 9 ноября 2010 года Apache Software Foundation пригрозила выйти из Java Community Process, если ей не будет предоставлена лицензия TCK для Harmony без каких-либо дополнительных ограничений. 9 декабря 2010 года Apache Software Foundation сложила с себя полномочия члена Исполнительного комитета Java SE/EE.