инверсия вне
Сижу пишу код сегодня, тестирую только что написанный метод JUnit'ом.
Серия тестов выглядит примерно так:

assertSame("AA должно ровняться 0", 0, myMethod("AA" ));
assertSame("AB должно ровняться 27", 27, myMethod("AB" ));
assertSame("FB должно ровняться 157", 157, myMethod("FB" ));

У assertSame второй параметр это заданное тобой контрольное значение, третий - то что ты проверять собрался, а первый - текст ошибки, который ты увидишь в случае провала теста.

Запускаю тесты и смотрю как они крашатся. Причём, первые 2 случая отрабатывают отлично, а в последнем внезапно получаю:

java.lang.AssertionError: FB должно ровняться 157 expected same:<157> was not:<157>
(типа 157 не равно 157)

Протираю монитор и очки, делаю зум на +50% и смотрю на это вот так вот @_____@. Первой мыслей было, что наверно же там какие-нибудь левые непечатаемые символы, так что проверила вывод HEX плагином в NotePad++, и результат показал, что в обоих случаях-таки указан один и тот же набор символов, так что непечатаемые символы тут ни при чем. Второй мыслей было "тра-ля-ля-ля, я сошла с ума!" посмотреть чО покажет дебагер. Дебагер показал, что в обоих случаях мы имеем 157. Позвала коллегу посмотреть на такие внезапности. Посмотрели с ним вместе, сделали ещё раз тож самое что и я до этого, а потом чё-то как-то вспомнилось.
Хитрая Java хранит числа в диапазоне от -128 до 128 особым способом, зарезервировав для них место заранее (насколько я помню, чтоб не тратить время на создание нового объекта), а на всё остальное создаётся новый объект. А метод реализован так, что сравнивает по ссылке. Поэтому-таки, да, 157 и 157 - два разных объекта никак между собой не равных по ссылке! Вот...
Заюзала вместо assertSame метод assertTrue теперь всё работает.
Но в целом это, пожалуй, первый раз, когда мне пригодились хитровыдуманные знания из теста SCJP, забавно даже =)


@темы: IT