Mockito. Из чего он приготовлен и как его подавать?

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

В вашем приведенном примере действительно можно обойтись без mock-фреймворка (хотя там даже тестировать нечего). И во многих других случаях также можно обойтись без них. Но также в очень многих приложениях нужно "мокнуть" какой-то большой класс, у которого есть не только метод getName, а множество других. Если использовать ваш подход то придется для каждого из них писать имплементацию метода. А теперь добавьте к этому то, что тестируемый класс может менять свою структуру (добавятся новые методы, какие-то удалятся и тд). В каждом их этих изменений вам придется менять свой MockApple.

Также эти "нюансы" работы mock-фреймворков (и речь не только про when-thenReturn) позволяют вам, например, возвращать какое-то конкретное значение в зависимости от входных данных прямо в самом юнит-тесте. Например, вы можете генерировать различные входные данные и проверять их выход (хотя с точки зрения тестирования это может быть не совсем верный подход)

Таким образом, использовать mockito и подобные фреймворки во всех тестах, разумеется, необязательно. Но обычно плюсы, которые дает этот фреймворк перевешивают его стоимость использования

Как получилось, что 0,1 + 0,2 = 0,30000000000000004?

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

Кстати, еще один кейс для Java:

double a = 2.5 + 5/10;   // = 2.5

Думаю, все это относится к мелочам, которые довольно важно знать (в том числе и переполнения)

Java Core для самых маленьких. Часть 1. Подготовка и первая программа

И добавить к этому еще «Effective Java» Блоха и «Чистый код» Фаулера и полный стартер пак будет собран. Ну, а для тех кому это мало им уже можно лезть в спецификации.

Имхо тоже считаю, что Философия Java — это отличная книга (хоть и соглашусь что для начинающего немножко сложная). Но ведь необязательно прочитать книгу за присест. Я вот, например, одну книгу «Введение в Java EE» Дашнера читал, наверное, на протяжении года, и то некоторые описанные паттерны я до сих не особо понимаю.

Вы часто используете null? А он у нас в спецификации

Если мы вызываем метод getCookies(), то мы как бы подразумеваем, что в этом объекте условно есть поле cookies.

Я не отрицаю что оно может быть null. Под есть я имел в виду просто наличие поля (условно и оно может быть null) (чтобы легче было представить как Java объект).

И полностью согласен с последним. Если Jetty имеет правильную реализацию (а скорее всего это так), то нет смысла возвращать null (точнее есть, но пустой массив был бы лучшей альтернативой)

Вы часто используете null? А он у нас в спецификации

Спасибо за ваше мнение. Это первая нормальная причина использования null в этом контексте. Тем не менее, я бы не сразу согласился.

Давайте посмотрим на HttpServletRequest как Java-объект. Если мы вызываем метод getCookies(), то мы как бы подразумеваем, что в этом объекте условно есть поле cookies. И с этой точки зрения мне кажется вполне допустимо возвращение пустого массива, так как куков нет (и не важно почему, их просто нет). По сути это означает, что данный объект не содержит куки.

Более того, иногда было бы полезно ловить ситуации, что сервер не обрабатывал запрос не просто потому, что header содержит некорректные данные, а потому что такого header'а вообще нет (из-за блокировщика рекламы или из-за ошибки в реализации клиентской части).

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

Вот листинг из Jetty:

if (cookies == null || cookies.getCookies().length == 0)    
	return null;
return _cookies.getCookies();

Как расширить Spring своим типом Repository на примере Infinispan

Было бы очень хорошо, если вы поправите листинги кодов. А именно отступы (сделать их меньше и делать переводы строк), чтобы при отображении листинга она не резалась.
Потому что довольно трудно читать такой формат

Я конечно понимаю, что это спринг и имена бинов обычно имеют космическую длину, но можно постараться :)

Например

Разработана опенсорсная утилита Depix для восстановления паролей с размытых скриншотов

Что ж, пойду удалять запикселенные фото, хотя вряд ли это поможет :)

Hello World из байт-кода для JVM

Я сейчас прочитал статью, которую вы приложили. Лично мне кажется, что официальная спецификация JVM будет более понятной, чем эта приложенная статья. По крайней мере, считаю, что она, возможно, была нацелена на людей, которые уже знают (хорошо) структуру байт-кода. Если вас просто смутило одинаковое название и тема статей, то не думаю, что это то из-за чего статью можно назвать копией. Так как у нас совершенно разные методы изложения.

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

Опыт создания игры для Android в одиночку с нуля и как ее зафичерили на Google Play

Посмотрел в Google Play, вроде классная, попробую как-нибудь вечерком. И да, было бы интересно узнать сам процесс разработки.

Мой путь начинающего разработчика игр

Оффтоп. А куда поступать собираешься или сразу пойдешь разработчиком?

Мой путь начинающего разработчика игр

Тут сыглы. То чувство, когда ты потратил полгода, чтобы изучить язык ( и всего-то Java Core с JavaFX в придачу), а кто-то за один вечерок по спидрану. Эхх....