Лучшие модульные тесты на основе JUnit с подсказками по бета-версии NetBeans 7.4

В своем последнем посте я писал о подсказках, представленных в бета-версии NetBeans 7.4, которые улучшают способность разработчика избегать неприятных проблем во время выполнения с обработкой исключений Java. В этой статье я расскажу о том, как использовать еще две подсказки, предоставляемые бета-версией NetBeans 7.4, чтобы сделать модульные тесты более правильными и понятными во время выполнения модульных тестов. Это подсказки «Необратимые параметры Assert.assertEquals» и «Неверный порядок параметров Assert.assertEquals».

Насколько я могу судить по неподтвержденным данным и общению с другими разработчиками Java, JUnit остается наиболее широко используемой средой модульного тестирования в среде Java. Большинство из этих пользователей JUnit близко знакомы с классом Assert JUnit и его многими перегруженными методами assertEquals . В бета-версии NetBeans 7.4 теперь есть две подсказки, облегчающие правильное использование этих методов assertEquals .

Хотя многие из методов Assert.assertEquals() имеют очень специфические типы данных для «ожидаемых» и «фактических» параметров, которые должны быть утверждены как равные, существует версия, которая принимает два объекта, и это означает, что два параметра разных типов не могут считать «равным», тем не менее можно передать этот метод. Компилятор не может предотвратить это, но бета-версия NetBeans 7.4 содержит подсказку «Необратимые параметры Assert.assertEquals» для решения этого конкретного случая. Без такого намека человек, скорее всего, не осознает ошибки своих путей, пока он или она не выполнит тест JUnit и не увидит ошибочное утверждение.

Одна из наиболее распространенных проблем, с которыми я столкнулся в JUnit (и одна из причин, по которой я люблю свободный API Hamcrest ), заключается в том, что я просто не могу с уверенностью вспомнить, с каким порядком располагаются параметры для методов assertEquals . У меня есть 50/50 шанс быть правильным, угадывая. Современные Java IDE, такие как NetBeans, очень помогают при написании нового кода JUnit, потому что их функции завершения метода будут указывать, что «ожидаемый» параметр указан первым, а «фактический» параметр — вторым. Чаще всего это проблема при чтении кода, а не при его написании, потому что нет завершения метода, помогающего мне прочитать код. Бета-версия NetBeans 7.4 решает эту проблему, выделяя ситуацию, в которой я перепутал порядок параметров с помощью подсказки «Неверный порядок параметров Assert.assertEquals». С этой подсказкой (которая используется по умолчанию) я могу быстро распознать неупорядоченные параметры перед выполнением и даже без завершения метода.

Обе подсказки, рассмотренные выше, могут быть продемонстрированы в очень простом классе модульного тестирования.

Часть CalculatorTest.java

Код, который тестирует метод вышеупомянутого модульного теста, не важен для этого обсуждения. Скорее, основное внимание уделяется использованию Assert.assertEquals в двух случаях. Оба случая, как показано выше, являются неверными и вызывают принудительную демонстрацию двух ранее обсужденных подсказок NetBeans. Первая попытка утверждения двух объектов — это размещение параметров в неправильном порядке. «Ожидаемое» значение (жестко закодированное 15) должно быть указано первым, а затем «фактическое» значение, рассчитанное с помощью тестируемого метода. Вторая попытка утверждать, что два объекта равны, всегда будет неудачной, потому что типы не совпадают: первый параметр — это строка, а второй — целое число. В обоих этих случаях код модульного теста компилируется без жалоб. Однако оба утверждения ВСЕГДА потерпят неудачу при запуске модульных тестов. На самом деле, результаты этих тестов могут быть непреднамеренно интерпретированы как проблемы с тестируемым кодом, пока кто-то не изучит сбои теста более подробно.

На следующих двух снимках экрана демонстрируется бета-тестирование NetBeans 7.4 с обоими утверждениями о проблемных утверждениях модульного тестирования.

Следует обратить внимание на одну оговорку, касающуюся подсказки «Неправильный порядок параметров Assert.assertEquals». Это хорошо работает, когда утверждение утверждение похоже на то, что показано в моем примере: жестко закодированное ожидаемое значение предоставляется в качестве «фактического» значения вместе с явно рассчитанным значением в качестве «ожидаемого» значения. Следующий снимок экрана иллюстрирует эту точку; только указание, которое я ранее показал, помечено подсказкой, а другие способы сравнения фактического с ожидаемым не помечены, даже если порядок неправильный.

Последний показанный снимок экрана демонстрирует, что подсказка NetBeans способна обнаруживать только неправильный порядок параметров assertEquals (следует ожидать до фактического, а не фактического до ожидаемого) в случае, когда к этим значениям непосредственно обращаются в операторе (фактический расчет выполняется для первого [ожидаемого] параметра, и ожидаемое жестко закодированное значение предоставляется для второго [фактического] параметра).

Две подсказки, описанные в этом сообщении, облегчают обнаружение проблем с часто используемыми методами JUnit Assert.assertEquals которые могут не обнаруживаться до анализа результатов запуска модульного теста без подсказок. Хотя две проблемы, о которых предупреждают разработчики, как правило, довольно легко обнаружить и исправить, обнаружение и устранение этих проблем все еще более сложное и трудоемкое, чем в IDE NetBeans, которые сообщают вам, что они не правы даже до запуска теста.