JMockit имеет какие-либо недостатки вообще?
- GCC не реализует rd.entropy () правильно - он всегда возвращает 0 (по крайней мере, в Mac OS X).
- К сожалению, похоже, что нет никакой возможности смешать дополнительную энтропию в random_device, что важно, потому что обычно / часто (посмотрите на Linux / dev / random и / dev / urandom, а также на реализацию Intel RDRAND) реализует генератор псевдослучайных чисел под капотом. Я бы хотел улучшить свой результат, введя что-то, что я считаю случайным, чтобы смешиваться с тем, что производит его источник энтропии. Опять же, поскольку это устройство (или модуль ядра) внутренне реализует криптографический алгоритм для обработки битов энтропии, которые он получает для генерации своего вывода, я хотел бы иметь возможность «рандомизировать» этот процесс больше путем инъекции мои собственные данные должны смешиваться с любой энтропией, которую выбирает устройство. Например, рассмотрим Java SecureRandom (). Это не позволяет вам устанавливать семя (которое действительно преобразует его в PRNG), но оно будет радостно смешивать то, что вы предоставляете, тем, что оно использует, чтобы «рандомизировать» свой результат еще больше.
- Я лично предпочитают RDRAND. Небольшая сборная библиотека с компактным интерфейсом C. Вот ссылки: Дэвид Джонсон из Intel объясняет RDRAND на Stackoverflow Указатели Stackoverflow для источника библиотеки RDRAND для Windows, Linux и Mac OS X Блог Intel в библиотеке RDRAND , и ссылку для скачивания
2 ответа
Три недостатка:
- Вы должны использовать Java-агент для инструментации байткода.
- Вы не можете использовать подписанный файл junit.jar, поставляемый с Eclipse.
- Вы должны изучить API mock. (В отличие от объекта-заглушки)
Вы всегда можете обсудить, хорошо ли это - иметь возможность издеваться над конечным классом, как это делает JMockit. Если только это не старый код, рефакторинг обычно является лучшей альтернативой.
В последнее время в таких IDE, как Eclipse, я чаще использую поддержку инструментов для генерации заглушек внутри тестового класса, чем насмешки (JMockit, Mockito и т.д.). Преимущество этого подхода в том, что он очень прост. Это особенно хорошо, когда у вас в команде много разработчиков, и некоторые из них не любят тестирование и не имеют достаточной мотивации для изучения mocking-фреймворка. Кроме того, реализации заглушек не имеют ограничений фреймворка!
Если вы готовы использовать заглушки в качестве альтернативы, вам стоит заглянуть в блог Роберта К. Мартина о мокинге и заглушках здесь и здесь
В остальном, это выглядит очень хорошо! Хотя у меня есть только опыт работы с JMock, EasyMock и базовые знания о JMockit.
Недавно я принял проект, использующий JMockit, и я думаю, что качество кода, безусловно, пострадало из-за способности библиотеки макетировать статические и частные методы.
Тесты очень хрупкие, потому что тестируются детали реализации, содержащиеся в частных методах (поэтому, если я изменю , как класс делает что-то, он может нарушать тесты, даже если что ] класс не был затронут).
Код также изобилует вызовами статических методов - если бы разработчики не имели возможности их смоделировать, то я думаю, что они приложили бы больше усилий, чтобы разделить вещи немного лучше.