Я хочу рассказать про Vaadin — фреймворк для разработки веб-приложений на Java. Да, на Java этих фреймворков — пруд пруди, но Vaadin заметно выделяется среди них.

Чем Vaadin отличается от других Java web фреймворков?

Если вкратце, Vaadin позволяет писать веб-приложение в стиле Swing:

import com.vaadin.ui.*;

public class HelloWorld extends com.vaadin.Application {

    public void init() { 
        Window main = new Window("Hello window"); 
        setMainWindow(main);
        main.addComponent(new Label("Hello World!")); 
    }
}

Считается преимуществом, при использовании Vaadin приходится программировать только на одном языке — Java, то есть не надо заморачиваться с XML, JavaScript, Html и т.д. и можно вовсю использовать весь мощный инструментарий Java: рефакторинг, юнит-тесты, заглушки (моки) и т.д. Ты пишешь new Label("Hello World!"), а Vaadin сам уже ломает голову, как это превратить в Html и JavaScript.

Вопрос

Очень часто при обсуждении программ употребляется термин «логика» или «бизнес-логика».
Например:

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

Так вот, кто скажет мне, что такое «логика»? Надо ли понимать под этим любой IF в коде? Но разве бывает код без IF'ов? Или (бизнес-)«логика» означает любую информацию, которая исходит от клиента? Но разве можем мы на деньги клиента делать что-то, чего он не заказывал? Не можем. Стало быть, весь наш код — это целиком «бизнес-логика» от клиента. Вот поэтому я никогда не мог понять, что же такое эта чёртова логика.

Один из самых восхитительных примеров кода, который я когда-либо встречал.
Как сказано в комментарии, этот код пытается найти в строке подстроку «Nothing», «Successful», «Password» или «Failed», причём регистр первой буквы неважен.

protected void parseSummaryLines()
{
   ...

   // NOTE: First letters are ommited in order to
   // support capitalized words as well
   String RESULT_GOOD_TEXT_1 = "othing"; // Nothing
   String RESULT_GOOD_TEXT_2 = "uccessful"; // Successful
   String RESULT_BAD_TEXT_1 = "assword"; // Password
   String RESULT_BAD_TEXT_2 = "failed"; // Failed

   ...
}


Можно относиться к нему по-разному. С одной стороны, можно усмотреть в этом говнокод. С другой стороны, это простое и лаконичное решение, которое вполне справляется с поставленной задачей.

Но в любом случае, получившееся в результате «Жопослово» — это шедевр…

Много слов сказано о достоинствах юнит-тестов (TDD, BDD — в данном случае неважно), а также о том, почему люди всё-таки их не используют.

Но я думаю, что одна из главных причин заключается в том, что люди не знают, с чего начать. Вот прочитал я статью про юнит-тесты, понравилось; решил, что надо бы когда-нибудь попробовать. Но что дальше? С чего начать? Как придумывать все эти требования, как называть тест-методы?

В последнее время набирает популярность тенденция превращать юнит-тесты в BDD-спецификации, то есть говорится о том, что хороший юнит-тест должен не тестировать что-то, а описывать поведение программы. Но как описать это чёртово поведение; откуда брать вдохновение, чтобы придумать названия для всех этих тест-кейсов?

Об этом и пойдёт речь:

Перевод этой статьи уже был однажды опубликован на хабре, но там почему-то осталась за кадром самая важная часть. Ниже — полный перевод.

На написание этой статьи меня вдохновила заметка "Как бы вы написали факториал на Java?". Так что извините, я немного поразглагольствую в коде: у меня есть главная мысль, которую я выскажу в конце.

Если вам надо написать факториал на Java, то большинство из ваc, вероятно, начнёт с чего-нибудь

Один из самых частых ответов на вопрос «Почему я не пишу юнит-тесты» — это вопрос «А кто напишет тесты для моих тестов? Где гарантия, что в моих тестах тоже не будет ошибки?», что свидетельствует о серьёзном недопонимании сути юнит-тестов.

Цель этой заметки — коротко и чётко зафиксировать этот момент, чтобы больше не возникало разногласий.

Итак, юнит-тест — это

Я глубоко верю в методику TDD (разработка через тестирование), так как видел на практике пользу от неё. Она выводит разработку ПО на новый уровень качества и зрелости, хотя она до сих пор не стала повсеместно распространённой. Когда наступает момент выбора между функциональностью, временем и качеством, всегда страдает именно качество. Мы обычно не хотим потратить больше времени на тестирование и не хотим идти на уступки в количестве выпускаемой функциональности. Если вы не планировали использовать методику TDD с самого начала проекта, то потом очень трудно перейти на неё.

Все мы слышали

Посетителям сайта stackoverflow.com был задан вопрос: «Какие программерские термины вы придумали, так чтобы они стали популярны в ваших кругах (то есть вы слышали, что кто-то их повторяет)?

Ниже — вольный перевод самых популярных ответов.

Много слов сказано о том, как правильно писать юнит-тесты, и вообще о пользе TDD. Потом ещё и какое-то BDD замаячило на горизонте. Приходится разбираться, что из них лучше и между ними какая разница. Может, это и есть причина, почему большинство разработчиков решили не заморачиваться и до сих пор не используют ни того, ни другого?

Коротко: BDD — это дальнейшее развитие идей TDD, стало быть, его и надо использовать. А разницу между TDD и BDD я попробую объяснить на простом примере.

Рассмотрим 3 ревизии одного юнит-теста, который я нашёл в одном реальном проекте.

Попытка номер №1

Первая версия этого юнит-теста была такой:

Программистов часто обвиняют в том, что они делают свою работу неряшливо. В природе существует бесчисленное количество программ, которые падают, зависают или неожиданно пишут на экране «Превед медвед» миллион раз.

Часто ли у так бывает, что вы встречаете плохой код и мысленно ругаете автора?
А потом приходите к выводу, что код не так уж и плох, и автора ругали зря… Но осадок-то остался!

В общем, медитировал я давеча перед монитором, и посетил меня

Быстро! Ответьте на следующий вопрос:

Как вы оцениваете свой уровень как программиста (ниже среднего, средний, выше среднего)?

Согласно психологическим опросам среди разных групп, около 90% программистов отвечают «Выше среднего».

Очевидно, это не может быть правдой.

Видео с живой демонстрации техники «ping-pong programming» (разновидность парного программирования), показанной на встрече DevClub в сентябре 2009 года:

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

Компания SUN даже придумала специальный формат javadoc — «стандарт для документирования классов Java». В моей практике было совершенно обычным явлением, когда какой-то код не проходил Code Review, потому что в нём у некоторых методов отсутствовали комментарии.

Я утверждаю, что этот подход устарел, и сегодня я расскажу, почему комментарии — это зло.