Complexity is the path to the dark side
Complexity is the path to the dark side
Горячие новости!
Mockito только что выпустил версию 3.4.0, в которой он умеет мокать статические методы.
На днях мир был ошеломлён неожиданной новостью.
Шутки ли, вышла Mockito 2.1.0 - после стольких лет ожиданий! Признаться, я уж было отчаялся.
В Mockito 2 обещается много всяких вкусняшек, включая:
Ура! Надо брать!
Какое же меня ждало разочарование…
Шесть лет назад я писал энтерпрайзный проект на Spring framework.
Мы все считали, что Spring - это кровавый энтерпрайз.
Мы хотели избавиться от этого бойлерплейта.
Мы были молоды, мы были горячи, мы хотели перемен.
Моё интервью для jug.ru о Legacy-коде без максимализма: что делать.
Про TDD, спорт, Шелока Холмса и реальных пацанов.
Это мой ответ на статью о том, почему разработчики не могут быть хорошими тестировщиками.
вы можете научить собаку нескольким трюкам, но вы уж точно не сможете научить ее летать.
Всё это полная ерунда! Собаку нельзя научить летать, потому что она физически по-другому устроена. А разработчики и тестировщики устроены ОДИНАКОВО!
Недавно я писал о том, что на самом деле нельзя хардкодить.
Давайте рассмотрим этот принцип на примере пэдж объектов.
Это страшное слово - хардкод. Все боятся это сделать, но иногда каждый из нас это делает.
Но я утверждаю, что хардкод в привычном нам понимании вовсе не так уж страшен, и на самом деле гораздо страшнее, когда в коде прописывают кое-что иное.
Так что же на самом деле нельзя хардкодить?
Как правило, для тестов нужно создавать много разных объектов с самыми разными состояниями. Не всегда есть подходящие конструкторы, и плодить их особо не хочется.
И вот тут неожиданно на помощь приходит Java 8! Казалось бы, при чём тут?
А вот при чём.
Канун Нового Года - время чудес. В преддверии нового года мы все вспоминаем год уходящий и строим планы на следующий. И надеемся, что все проблемы останутся в прошлом, а в новом году случится чудо, и мы заживём по-новому.
Какой же Java разработчик не мечтает о чуде, которое осенит его и позволит стать Самым Крутым На Свете Java Программистом.
Хорошие новости: я хочу рассказать как раз о таком чуде.
Имя ему - автоматические тесты!
Принято считать, что есть «вечные» вопросы, на которые нет правильного ответа. Например, что лучше: Windows или Linux, Java или C#; Чужой против Хищника или Чак Норрис против Ван Дамма.
Одним из таких холиваров считается выбор лучшей IDE для Java.
Очень часто при обсуждении программ употребляется термин «логика» или «бизнес-логика». Например:
Так вот, кто скажет мне, что такое «логика»?
Много слов сказано о достоинствах юнит-тестов (TDD, BDD — в данном случае неважно), а также о том, почему люди всё-таки их не используют.
Но я думаю, что одна из главных причин заключается в том, что люди не знают, с чего начать. Вот прочитал я статью про юнит-тесты, понравилось; решил, что надо бы когда-нибудь попробовать. Но что дальше? С чего начать? Как придумывать все эти требования, как называть тест-методы?
Много слов сказано о том, как правильно писать юнит-тесты, и вообще о пользе TDD. Потом ещё и какое-то BDD замаячило на горизонте. Приходится разбираться, что из них лучше и между ними какая разница. Может, это и есть причина, почему большинство разработчиков решили не заморачиваться и до сих пор не используют ни того, ни другого?
Коротко: BDD — это дальнейшее развитие идей TDD, стало быть, его и надо использовать. А разницу между TDD и BDD я попробую объяснить на простом примере.
Рассмотрим 3 ревизии одного юнит-теста, который я нашёл в одном реальном проекте. Мы увидим, как он меняется от “обычного” до “хорошего” и “полезного”.
Есть мнение, что хорошая программа должна быть хорошо задокументирована.
Компания SUN даже придумала специальный формат javadoc - “стандарт для документирования классов Java”. В моей практике было совершенно обычным явлением, когда какой-то код не проходил Code Review, потому что в нём у некоторых методов отсутствовали комментарии.
Сегодня я расскажу, почему комментарии - это зло.