Тестирование кода, предназначенного для более старой виртуальной машины Java, с использованием тестовой системы, работающей под более новой виртуальной машиной

Question

У нас есть библиотека, написанная для (и работающая на) более старой Java-виртуальной машины, в частности, 1,3 ME.

Даст ли он неточные результаты при использовании «современного» тестового жгута, работающего под виртуальной машиной 1.6 для проверки функциональности библиотеки?

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

Есть ли конкретные области, где эта модель выходит из строя, или где разные виртуальные машины могут привести к ложным результатам тестирования? Очевидно, что при использовании библиотеки можно использовать огромные преимущества, такие как универсальные шаблоны и современные тестовые наборы, но они будут отменены, если тесты недействительны.

Чтобы объяснить причину этого: мы пишем код, который работает на устройствах с конкретными виртуальными машинами (например, телефоны Blackberry и Android), поэтому мы разрабатываем и кодируем для общих API, где это возможно. Мы можем кодировать для разумного общего подмножества Java, но когда дело доходит до тестирования, запустите бизнес-логику на наших настольных компьютерах, где у нас есть доступ к виртуальным машинам, которые предоставляют лучшие возможности для надежного тестирования (например, инфраструктуры, такие как EasyMock и т. Д.).

Answer 1

Я думаю, что (технически) модульное тестирование логики вашего Java-классов в вашем приложении будет хорошо на более новой виртуальной машине, и, как вы говорите, языковые преимущества облегчат эту задачу.

Хотя я должен сказать, что немного странно писать тесты для классов, которые уже скомпилированы.Предположительно, если вы обнаружите ошибки, вам придется их исправить и на 1.3, что может раздражать разработчиков, постоянно меняющих тесты JUnit на 1.6 и код на 1.3.

Похоже, что вы действительно хотите делать вВ этом случае проводится некоторое интеграционное тестирование, доказывающее, что старые классы по-прежнему будут работать на своих старых виртуальных машинах.Если бы это был я, я бы для простоты сохранил бы все на 1.3 - но это действительно зависит от цели тестовых классов.Если в один прекрасный день вы намереваетесь перейти на 1.6, тогда тесты нового стиля будут лучше в долгосрочной перспективе.

Извините!Не очень убедительный ответ в конце концов!:)

Answer 2

Не думаю, что я бы порекомендовал тестировать в среде, которая сильно отличается. Вот альтернативное решение для вас, хотя. Напишите свой тестовый комплект с Java 1.6 и используйте Retroweaver , чтобы сделать его совместимым с 1.3. Затем запустите тестовую среду на 1.3, как будто она будет использоваться в реальном мире. Вы сможете использовать дженерики и современные библиотеки. Однако вы не сможете использовать функции из среды выполнения Java после версии 1.3. Возможно, это разумный компромисс, позволяющий тестировать ту же среду, в которой будет использоваться библиотека.

Answer 3

Возможно.

Я предполагаю, что библиотека времени компиляции - это 1.3 JVM (а не просто цель версии класса).В противном случае вы можете получить ошибки метода / класса / поля не найдены и т. П.

Если часть кода была написана для реализации, а не для абстракции, вы можете получить ошибки.То есть разработчик полагается на наблюдаемое поведение («Я попробовал, и это сработало») , а не на то, что было задокументировано в документации 1.3.

В более ранней среде выполнения могут появляться ошибки, которыенет в более новом.Могут быть обходные пути, но проблема не будет обнаружена в новой среде выполнения.