Andrei Solntsev

Mockito научился мокать статические методы!

2020-07-11T00:00:00+00:00

Горячие новости!

Mockito только что выпустил версию 3.4.0, в которой он умеет мокать статические методы.

Раньше Mockito этого не умел. Умел мокать только нестатические методы. Зато PowerMock умел. Но PowerMock делал это очень медленно, ведь для этого он подменял загрузчик классов (classloader), и весь тест запускал в нём. И перед каждым тестов инициализировал загрузчик классов заново.

А вот новый способ от Mockito 3.4.0 должен быть значительно быстрее, потому что у него меньше скоп: он мокает статический метод только в рамках одной маленькой лямбды. Изящно.

Давайте попробуем!

Шаг 1: зависимость

В нашем build.gradle меняем mockito-core:3.3.3 на mockito-inline:3.4.0:

testImplementation('org.mockito:mockito-inline:3.4.0')

Шаг 2: что мокаем

Предположим, у вас есть некий класс со статическим методом, который вы хотите замокать в тесте:

class Buddy {
  static String name() {
    return "John";
  }
}

Шаг 3: Мокаем статический метод

Для этого нужно использовать метод Mockito.mockStatic():

@Test
void lookMomICanMockStaticMethods() {
  assertThat(Buddy.name()).isEqualTo("John");

  try (MockedStatic<Buddy> theMock = Mockito.mockStatic(Buddy.class)) {
    theMock.when(Buddy::name).thenReturn("Rafael");
    assertThat(Buddy.name()).isEqualTo("Rafael");
  }

  assertThat(Buddy.name()).isEqualTo("John");
}

Всё. Mockito подменяет статический метод только в рамках try/catch блока. Быстро и эффективно ( Насколько это быстро, пока проверить не успел, извиняйте. :) ).

Больше примеров вы можете найти в тестах самого Mockito.

Отличная работа, Rafael Winterhalter!

NB! Не забывайте, что статические методы - зло, и старайтесь их по возможности не использовать.

Андрей Солнцев

asolntsev.github.io

Mockito can mock static methods!

2020-07-11T00:00:00+00:00

Hot news!

Mockito just released version 3.4.0 which can now mock static methods.

Before 3.4.0, Mockito could not mock static methods. It could only mock non-static methods. Though, PowerMock could. But PowerMock did it slowly: it replaced a classloader for every test, and executed the whole test within this classloader.

And the new Mockito 3.4.0 way should be more effective because it has narrower scope: it mock the static method only within one small lambda. Graceful.

Let’s try it!

Step 1: dependency

In your build.gradle replace mockito-core:3.3.3 by mockito-inline:3.4.0:

testImplementation('org.mockito:mockito-inline:3.4.0')

Step 2: what are we going to mock

Let’s assume we have a class with static method (that we want to mock in test):

class Buddy {
  static String name() {
    return "John";
  }
}

Step 3: Mock the static method

We can use new method Mockito.mockStatic() for this:

@Test
void lookMomICanMockStaticMethods() {
  assertThat(Buddy.name()).isEqualTo("John");

  try (MockedStatic<Buddy> theMock = Mockito.mockStatic(Buddy.class)) {
    theMock.when(Buddy::name).thenReturn("Rafael");
    assertThat(Buddy.name()).isEqualTo("Rafael");
  }

  assertThat(Buddy.name()).isEqualTo("John");
}

That’s it.
Mockito replaces the static method only with the try/catch block. Fast and simple (I haven’t checked how fast is it actually, sorry. :) )

You can see more example in Mockito own tests.

Great job, Rafael Winterhalter!

NB! Don’t forget static methods are evil. Try to avoid them if possible.

Andrei Solntsev

asolntsev.github.io

Миграция на Mockito 2.1

2016-10-11T00:00:00+00:00

На днях мир был ошеломлён неожиданной новостью.

Шутки ли, вышла Mockito 2.1.0 - после стольких лет ожиданий! Признаться, я уж было отчаялся.

В Mockito 2 обещается много всяких вкусняшек, включая:

Поддержка Java 8
Переход с CGLIB на ByteBuddy
Мокинг final классов и методов

Ура! Надо брать!

Какое же меня ждало разочарование…

Тотальный облом

Я попробовал перевести на Mockito 2.1.0 свой рабочий проект, и … облом. Я получил больше 100 красных юнит-тестов (из ~6000).

Моя первая эмоция - какого чёрта! В топку этот Mockito 2!

Но при ближайшем рассмотрении оказалось, что Mockito 2 молодец, а вот эти тесты - плохие. Новый Mockito обнаружил в моих тестах целый ряд проблем, который старый Mockito не замечал. Вот оно чо, Мокитыч…

Что надо сделать

Ниже - путеводитель по миграции на Mockito 2. Протяни руку, читатель, и проведу тебя по этому тернистому пути к счастливому финалу.

Первым делом ты заменишь импорты

Много, много импортов. Придётся поменять много файлов.

import static org.mockito.Matchers.any;
import static org.mockito.Matchers.anyLong;
import static org.mockito.Matchers.anyVararg; // не нужен - меняем на any()

на

import static org.mockito.ArgumentMatchers.any;
import static org.mockito.ArgumentMatchers.anyLong;

Затем ты обновишь API функции doAnswer

Было:

when(userDeviceService.save(any(UserDevice.class)))
    .then(invocation -> invocation.getArgumentAt(0, UserDevice.class));

Стало (getArgumentAt -> getArgument, убираешь класс):

when(userDeviceService.save(any()))
    .then(invocationOnMock -> invocationOnMock.getArgument(0));

Дальше ты обновишь API isMock

Было:

  import org.mockito.internal.util.MockUtil;
  
  assertFalse(new MockUtil().isMock(expected));

Стало:

  import static org.mockito.internal.util.MockUtil.isMock;
  
  assertFalse(isMock(expected));

Новый вариант и правда лучше, не поспоришь. Не нужно создавать ненужный объект.

На какие грабли ты наступишь

При переходе на Mockito 2.1 cотня-другая твоих тестов сломается, потому что:

1) Матчер `any()` больше не срабатывает на `null`

Раньше это работало:

doNothing().when(service).calculateAmounts(any(BigDecimal.class), anyString());

Теперь не работает, если хотя бы один из параметров - null. Да-да, мой друг, тебе придётся перелопатить все тесты, которые почему-то передают null вместо настоящего значения, и прописать там правильные значения.

Но это и к лучшему, ведь и правда новый код лучше:

doNothing().when(service).calculateAmounts(order.amount, order.currency);

или, может, так:

doNothing().when(service).calculateAmounts(new BigDecimal("100.00"), "EEK");

Забыл сказать: если там действительно должен передаваться null, то это в тесте надо прописать явно:

doNothing().when(service).calculateAmounts(any(BigDecimal.class), isNull());

2) Матчер anyInt() больше не срабатывает на параметр типа long

Работало с Mockito 1.x, падает с Mockito 2.x:

    when(mqService.send(anyString(), anyInt())).thenReturn("transfer-ref");

Для Mockito 2.1 придётся поменять anyInt() на anyLong():

    when(mqService.send(anyString(), anyLong())).thenReturn("transfer-ref");

Да-да, мой друг, тебе придётся перелопатить все тесты, которые вместо long передают int и т.п. Но это и к лучшему, ведь эти тесты были неточные.

3) Ты обнаружишь у себя плохие тесты

Просто плохие. Негодные. Например, вот такой:

@Test
public void checkMoratoriumRunsSilentlyWhenNoMoratorium() {
  doReturn("false").when(service).parseMoratoriumMessage(any(Mandate.class), any(LoanApplication.class));
  ...
  service.checkForMoratorium(any(Mandate.class), any(LoanApplication.class)); // Какую хрень мы сюда передаём?
  ...
}

С Mockito 1.x этот тест работал, а с Mockito 2.1 уже не хочет. И правильно!

Очевидно, во второй строке хотели использовать mock, а не any:

service.checkForMoratorium(mock(Mandate.class), mock(LoanApplication.class));

Хотя мы-то с вами понимаем, что тут не нужен ни mock, ни any, а достаточно просто создать объекты:

service.checkForMoratorium(new Mandate(), new LoanApplication());

4) Ты обнаружишь у себя много неряшливых тестов

… которые проверяют лишь часть параметров и не замечают, что остальные - null.

doReturn(user).when(loginService).tokenLogin(eq("bob"), eq("login-key"), anyString());
    
security.login("bob", "login-key", null);

Как видите, во второй строке тест передаёт параметр null. И только null. Расследование показало, что ни один тест в системе не передавал туда ничего, кроме null.

Новый тест гораздо точнее, и не нужны все эти eq и anyString:

    request.remoteAddress = "127.0.0.2";
    doReturn(user).when(loginService).tokenLogin("bob", "login-key", "127.0.0.2");
    ...

5) Ты обнаружишь мистические красные тесты

Ты обнаружишь красные тесты, причину падения которых очень сложно раскопать

Например, такой:

@Test
public void requestByReferenceNumberNeverCreatesSubscription() {
  RequestByReferenceNumber requestByReferenceNumber = new RequestByReferenceNumber(user, "12345678901234567890");
  when(gisgmpService.request(any(RequestByDrivingLicense.class))).thenReturn(requestByReferenceNumber);

  GISGMP.requestCharges("12345678901234567890");
  ...

С этим я долго провозился. Я не мог понять, почему он перестал работать.

Обратите внимание на вторую строку. Очевидно, там хотели написать не any(RequestByDrivingLicense.class), а any(RequestByReferenceNumber.class) (они оба наследуют один суперкласс).

Это похоже на багу Mockito 1: он позволял использовать any(НеверныйКласс.class), и этот некорректный тест оставался зелёным несколько лет. :(

6) Ты нарвёшься на то, что anyList() и anyCollection() - теперь разные вещи

Например, со старым mockito этот тест работал:

  @Test
  public void domesticPaymentInForeignCurrencyCanBeEnabled() {
    doCallRealMethod().when(Payments.accountService).forOperation(anyList(), eq(DOMESTIC));

    Collection<Account> accounts = ...
    
    return accountService.forOperation(accounts, DOMESTIC);

Обратите внимание, что в моке в первой строчке используется anyList(), а на самом деле передаётся переменная accounts типа Collection (хотя в душе она List). Mockito 2 больше не позволяет таких шалостей. Изволь прописать anyCollection().

И будешь доволен как слон

В общем, мой друг, придётся помучаться, но в конце будешь доволен. Тесты стали лучше, мир стал светлее.

Андрей Солнцев

asolntsev.github.io

Migration to Mockito 2.1

2016-10-11T00:00:00+00:00

Recently we got a great news.

They released Mockito 2.1.0 - after so many years of hopeless waiting!

There is a lot of cool updates in Mockito 2, including:

Support for Java 8
Migration from CGLIB to ByteBuddy
Mocking final classes and methods

Yes! I must use it! - I decided.

What a huge disappointment it was for me…

Epic fail

I tried to upgrade my working project to Mockito 2.1.0, and … ups.

I got over 100 red tests (from ~6000).

My first emotion was - what the hell! Mockito 2 sucks!

But the further investigation showed that Mockito 2 is cool, but some of my tests are bad. The new Mockito found a whole bunch of problems in our tests.

Let’s discover them together.

What you need to do

Below you can find my tutorial for migration to Mockito 2.

Let’s start!

First, you will need to replace import

A lot of imports. In many files. Replace these lines:

import static org.mockito.Matchers.any;
import static org.mockito.Matchers.anyLong;
import static org.mockito.Matchers.anyVararg; // not needed - replaced by any()

by these lines:

import static org.mockito.ArgumentMatchers.any;
import static org.mockito.ArgumentMatchers.anyLong;

Second, you will update API of doAnswer

Was:

when(userDeviceService.save(any(UserDevice.class)))
    .then(invocation -> invocation.getArgumentAt(0, UserDevice.class));

Now:

when(userDeviceService.save(any()))
    .then(invocationOnMock -> invocationOnMock.getArgument(0));

(getArgumentAt -> getArgument, remove the class)

Third, you update API of isMock

Was:

import org.mockito.internal.util.MockUtil;

assertFalse(new MockUtil().isMock(expected));

Now:

import static org.mockito.internal.util.MockUtil.isMock;

assertFalse(isMock(expected));

The last version is really better, don’t you think? No need to create an unused object.

What problems you will experience

Some of your tests will break when you upgrade to Mockito 2.1. Below you will find some of the reasons.

1) Matcher `any()` does not match `null` anymore

This code worked before:

doNothing().when(service).calculateAmounts(any(BigDecimal.class), anyString());

But doesn’t work anymore, if some of parameters are null. Yes, my friend! You will need to rework all your tests that pass null instead of realistic value.

And it’s great, because the new code is really better:

doNothing().when(service).calculateAmounts(order.amount, order.currency);

Or this way:

doNothing().when(service).calculateAmounts(new BigDecimal("100.00"), "EEK");

If you really need to pass null parameter, you can still do it. Just pass null explicitly using isNull matcher:

doNothing().when(service).calculateAmounts(any(BigDecimal.class), isNull());

2) Matcher anyInt() does not match long anymore

This code worked with Mockito 1.x, but fails with Mockito 2.x:

when(mqService.send(anyString(), anyInt())).thenReturn("transfer-ref");

You need to replace anyInt() by anyLong() for Mockito 2.1:

 when(mqService.send(anyString(), anyLong())).thenReturn("transfer-ref");

Yes, my friend. You will need to rework all your tests that pass int instead of long etc. But it’s great, don’t you think? Because these tests were inaccurate.

3) You will discover bad tests

Yes, my friend. You will discover lot of bad lines among your tests. Just bad. Like this one:

@Test
public void checkMoratoriumRunsSilentlyWhenNoMoratorium() {
  doReturn("false").when(service).parseMoratoriumMessage(any(Mandate.class), any(LoanApplication.class));
  ...
  service.checkForMoratorium(any(Mandate.class), any(LoanApplication.class)); // WHAAAAAAAT?
  ...
}

This code worked with Mockito 1.x. Suddenly. But it fails with Mockito 2.1 - and it’s great, don’t you think?

Obviously, we should use mock instead of any in the second line:

service.checkForMoratorium(mock(Mandate.class), mock(LoanApplication.class));

By the way, even better solution is to avoid both mock and any and just create plain objects:

service.checkForMoratorium(new Mandate(), new LoanApplication());

4) You will discover a lot of sloppy tests

… that check only some parameters and don’t discover that others are null.

For example:

doReturn(user).when(loginService).tokenLogin(eq("bob"), eq("login-key"), anyString());
    
security.login("bob", "login-key", null);

As you see, tests passes null parameter in the second line. And only null! I discovered that there was no test that would pass something different from null there.

Mockito 2.1 will fail with such a sloppy test, because anyString() matcher doesn’t allow null anymore.

The newer test that works with Mockito 2.1 is actually more precise:

    request.remoteAddress = "127.0.0.2";
    doReturn(user).when(loginService).tokenLogin("bob", "login-key", "127.0.0.2");
    ...

You see it? You don’t need all these obscure eq and anyString. Much better!

5) You will discover mystical red tests

You will find some red tests for which it’s really hard to understand why they fail.

For example:

@Test
public void requestByReferenceNumberNeverCreatesSubscription() {
  RequestByReferenceNumber requestByReferenceNumber = new RequestByReferenceNumber(user, "12345678901234567890");
  when(gisgmpService.request(any(RequestByDrivingLicense.class))).thenReturn(requestByReferenceNumber);

  GISGMP.requestCharges("12345678901234567890");
  ...

It took quite a long time to solve this issue. I could not find out why this test started to fail with Mockito 2.

Please note the second line. Obviously authors wanted to write any(RequestByReferenceNumber.class) instead of any(RequestByDrivingLicense.class) (they both inherit the same superclass).

It seems to be a bug of Mockito 1: it allowed using any(AWrongClass.class), and this incorrect test have been green for several years. :(

6) You will find out that anyList() and anyCollection() are now different things

For example, this code worked with Mockito 1:

  @Test
  public void domesticPaymentInForeignCurrencyCanBeEnabled() {
    doCallRealMethod().when(Payments.accountService).forOperation(anyList(), eq(DOMESTIC));

    Collection<Account> accounts = ...
    
    return accountService.forOperation(accounts, DOMESTIC);

Note that mock in the first line uses anyList(), but the code actually passes variable accounts of type Collection (thought it’s actually List).

Mockito 2 doesn’t allow it anymore. You need to mock more precisely using anyCollection().

And you will be happy

To summarize: you will see a lot of pain, but you will become happy. The tests got better, the world got lighter.

Peace 2.1.0!

Andrei Solntsev

asolntsev.github.io

Spring boobs

2016-10-03T00:00:00+00:00

Шесть лет назад я писал энтерпрайзный проект на Spring framework.

Мы все считали, что Spring - это кровавый энтерпрайз.

Мы хотели избавиться от этого бойлерплейта.

Мы были молоды, мы были горячи, мы хотели перемен.

И понеслось!

В 2010 я попал в фирму Codeborne, в которой у нас появилась свобода делать проекты на всём, чём душа пожелает.

Моя душа желала много и разнообразно.

С тех пор я успел поделать проекты на:

на Struts2 (Java),
на Play 1 framework (Java),
на Ruby (Sinatra),
на Scala (Scalatra),
на Groovy,
на Python (Tornado framework),
на Kotlin,
на Ratpack,
на Vert.x,
и даже, прости господи, на PHP!

И что теперь

Разочаровавшись из-за медленной компиляции Scala,
помудохавшись со скриптами Groovy, которые ничерта не поддерживаются никакими IDE,
поогрёбши багов с динамическим Питоном, у которого все библиотеки ломаются при малейшем апгрейде,
натёрши мозоли на кнопках s, e, l, f - потому что в Python, сцуко, надо везде писать self. при вызове абсолютно любых методов!
поматерившись на Ruby, который влёгкую ломается из-за одной случайной строчки чёртового комментария в одной случайной чёртовой зависимости,
и - не побоюсь этого слова - понатрахавшись в многочасовых ночных дебагах с многочисленными извращённейшими косяками Play framework,

я стал искать что-то стабильное.

Что-то, на что можно положиться.

Что-то, что просто работает и делает то, что мне надо.

И вот…

И я снова попробовал Spring framework.

Решил дать ему второй шанс.

И оказалось, что

бойлерплейта в нём ничуть не больше, чем в Struts2.
он умеет перегружать классы на лету гораздо лучше, чем Play framework.
естественно, в нём всё логируется, записывается, загружается и читается из коробки. Без багов. Без косяков. Без неожиданностей. Без чёрной магии.
в нём почти невозможно писать спагетти код, потому что архитектура почти заставляет тебя всё делать правильно: сервисы, репозитории, идеальный dependency injection - тут просто негде накосячить.
в нём всё сделано для того, чтобы нам было легко писать автотесты.
- И юнит-тесты, и интеграционные. В одну команду - взлетает база данных, тестирует твой селект, умирает.
- И даже UI-тесты. В одну команду - взлетает приложение с БД, открывается браузер, всё прокликивается, умирает.
и вопреки легендам, в нём не нужен никакой чёртов XML.

Кто-нибудь помнит, за что мы тогда не взлюбили Spring?

Короче

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

Пойду пересмотрю “Москва слезам не верит”.

Андрей Солнцев

asolntsev.github.io

Spring boobs

2016-10-03T00:00:00+00:00

Six years ago I developed an enterprise project with Spring framework.

We believed that Spring is a bloody enterprise.

We wanted to get rid of this boilerplate.

We were young and courage, we wanted changes.

And it began!

At year 2010 I got to Codeborne company where we got a freedom to use whatever tools we wanted.

I wanted a lot of very different tools.

Meanwhile I developed projects with:

Struts2 (Java),
Play 1 framework (Java),
Ruby (Sinatra),
Scala (Scalatra),
Groovy,
Python (Tornado framework),
Kotlin,
Ratpack,
Vert.x,
and even PHP!

And what now?

Disappointed with

slow compilation Scala;
Groovy scripts that are not supported well by any IDE;
dynamic Python that fails with any upgrade;
annoying keyword self. that you must write in Python before every method call;
Ruby that can be broken by single random comment line in single random dependency;
endless night debugging sessions with unbelievably crazy Play framework bugs,

I started to look for something stable.

Something that I could rely on.

Something that simply works.

And then…

I decided to try Spring framework once again.

I decided to give it a chance.

And I found that

it contains no more boilerplate than Struts2 framework.
it can reload classes on the fly much better than Play framework.
it can log, save, and load data out of the box. With no bugs. With no issues. With no unexpected behaviour. With no black magic.
it almost doesn’t allow you to write spaghetti code because built-in architecture forces you to write good code: all these services, repositories, ideally implemented dependency injection - it’s just impossible to make it bad.
it does everything to allow you easily write automated tests.
- Both unit-tests and integration. With just one command - runs database, tests your select and dies.
- And even UI tests. With just one command - runs application with database, opens a browsers, clicks the buttons and dies.
and finally, it does not need any XML.

Does anybody still remember what we didn’t love Spring six years ago?

Finally

Maybe I am just getting old, but now I am ready to say that Spring is the best framework in the world. Better than anything that was created after it.

Andrei Solntsev

asolntsev.github.io

О Legacy-коде

2016-08-26T00:00:00+00:00

Моё интервью для jug.ru о Legacy-коде без максимализма: что делать.

Про TDD, спорт, Шелока Холмса и реальных пацанов.

About Legacy code

2016-08-26T00:00:00+00:00

My interview for jug.ru About Legacy code without maximalism.

Including: TDD, sport, Sherlock Holmes and real men.

Почему разработчики должны быть хорошими тестировщиками

2016-08-05T00:00:00+00:00

Это мой ответ на статью о том, почему разработчики не могут быть хорошими тестировщиками.

вы можете научить собаку нескольким трюкам, но вы уж точно не сможете научить ее летать.

Всё это полная ерунда! Собаку нельзя научить летать, потому что она физически по-другому устроена. А разработчики и тестировщики устроены ОДИНАКОВО!

По каждому приведённому пункту: если это могут тестировщики, то смогут и разработчики.

1. “Родительские чувства” к коду

Разработчики привязаны к тому, что они пишут. Может быть это прозвучит глупо, но очень сложно оценивать объективно то, что ты создаешь.

Вы могли обратить внимание на то, что нормальный родитель относится к своим детям наиболее требовательно. Я хочу, чтобы код - моё детище - хорошо работало, и чтобы ни у кого не было ни малейшей причины его критиковать. Поэтому я очень хочу найти в нём баги.

2. Акцентирование на позитивных моментах

Работа разработчика основывается на позитивных сценариях и их реализации в продукте. Чтобы работать тестировщиком нужно иметь диаметрально противоположный склад ума, так как тестировщики всегда акцентируются на негативных сторонах продукта нежели чем на позитивных. Следовательно разработчику нужно поменять склад ума, чтобы стать тестировщиком, а это не кажется столь реальным на мой взгляд.

Это правда, в период “созидания” я концентрируюсь на том, как СДЕЛАТЬ. Но я никогда на этом не заканчиваю. Потом наступает следующий период, когда я пересматриваю и улучшаю код, иногда по много раз. Перепроверяю и дописываю тесты. Критически думаю, а что там может СЛОМАТЬСЯ. Ведь я не хочу, чтобы моё детище критиковали.

Если разработчик после первого этапа считает дело сделанным, то это не разработчик, а ребёнок. Не надо по ним судить.

3. Работа на основе принципа упрощения сложных вещей

Рассматривание сложных сценариев с целью нахождения багов является одной из составляющих процесса тестирования. В двух словах мы берем простую вещь и придумываем как ее можно усложнить. Разработчики поступают ровно наоборот. Они берут сложный процесс или проект и разбивают его на более мелкие компоненты с целью найти решение проблемы.

Ровно то же самое, что п. 2. Вначале я упрощаю, потом усложняю.

4. Неспособность видеть мелкие детали на большой картине

Одним из основных качеств любого тестировщика является умение определить что не так на этой картине. Разработчики говорят, что у тестировщиков нюх на баги. Возможно это утверждение не так далеко от истины.

Это правда, такая проблема часто есть у разработчиков. Но если это могут сделать тестировщики, то могут и разработчики. У них точно такой же мозг.

Да не просто могут, а обязаны! Как иначе без видения общей картины они смогут хорошо спроектировать программу?

Если они сделают программу без учёта всего этого, а потом придут тестировщики и скажут, что не годится - это будет СЛИШКОМ ПОЗДНО! Придётся переписывать и потратить вдвое больше времени.

5. Недостаток опыта работы с типичными багами и программными ошибками

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

Да с какой это стати недостаток? Почему? За всю свою карьеру я сделал такое множество багов, что опыта работы с ними хоть отбавляй.

Я думаю, разработчики всё это прекрасно могут, но обычно не хотят. Тупо лень. А лень потому, что они знают, что они не последний рубеж. За ними есть ещё обезьянки-тестировщики, которые налетят и за них их работу сделают.

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

Тестировщики не могут обнаружить все неучтённые кейсы. Лишь некоторые.
Тестировщики не могут найти все баги. Лишь некоторые. Вы знаете, некоторые баги невозможно повторить.
Тестировщики-автоматизаторы не могут покрыть интеграционными тестами всё, что должно было быть покрыто юнит-тестами. Вы знаете, некоторые баги вообще невозможно покрыть интеграционными тестами, только юнит.

Мир катится в пропасть.

Андрей Солнцев

asolntsev.github.io

Настоящие пэдж-объекты

2016-07-09T00:00:00+00:00

Недавно я писал о том, что на самом деле нельзя хардкодить.

Давайте рассмотрим этот принцип на примере пэдж объектов.

Классический пэдж обжект

У тестировщиков-автоматизаторов очень популярен паттерн “Пэдж Обжект”. Собственно, это самый популярный в мире объект поклонения после статуи Будды в Лэшане и Шестого Айфона.

Суть его в том, что все селекторы, по которым ищутся элементы на веб-страничке тестируемого приложения, выносятся… точно, в константы:

public class RegistrationPage {
  @FindBy(name = "firstName")
  public WebElement firstName;

  @FindBy(name = "lastName")
  public WebElement lastName;

  @FindBy(name = "birthday")
  public WebElement birthday;
}

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

А тесты не нужно часто менять, потому что они используют пэдж объект:

  @Test
  public void userCanRegister() {
    RegistrationPage page = new RegistrationPage(webdriver);
    firstName.sendKeys("Bruce");
    lastName.sendKeys("Willis");
    birthday.sendKeys("19.03.1955");
  }

Такой подход стал особенно популярен с лёгкой руки Мартина Фаулера, который выдумал Золотое Правило Автоматизаторов:

В тесте не должно быть ни одного локатора. Локаторы должны быть спрятаны в пэдж объектах. Если в тесте виден локатор - это негодный тест.

В чём же подвох?

Мы забываем, что меняются не только локаторы. Как я рассказывал в изначальной статье, меняется логика работы с элементами. Допустим, есть у вас сотня тестов, в которых есть такая строчка:

birthday.sendKeys("19.03.1955");

Да, типа хорошо, если меняется локатор - сотня тестов останется нетронутой.

Но что если этот элемент из <input> вдруг превратиться в контрол типа “календарь”? Знаете, в котором нужно сначала кликнуть иконку календаря, потом выбрать год, потом месяц, и только потом день.

Упс!

Теперь вам придётся перелопатить всю сотню тестов. Да ещё и разобраться хорошенько, в каких нужно выбирать год, а в каких не нужно. В каких нужно менять месяц, а в каких не нужно. И как эти тесты будут работать в последний день месяца или года.

Упс! Всё пропало, шеф!

Что же делать?

Вот тут и вступает в силу правило: выносить нужно не константы, а логику. В пэдж объекте должно быть не поле birthday, а метод

public class RegistrationPage {
  public void enterBirthday(String birthday) {
  
    $(By.name("birthday")).sendKeys(birthday);
  
    // а потом - вся логика календаря здесь
  }
}

Вот теперь действительно, если поменяется логика работы с элементом “birthday” (в том число локатор!), ни один тест не поменяется - только пэдж объект.

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

Ну а в случае Selenide поля так и вовсе становятся ненужными, ведь гораздо легче использовать доллар (как в примере выше).

Вот это труёвый пэдж объект!

Контрольный в мозг

Давайте проверим, что мы понимаем друг друга правильно. Если вы согласны с приведёнными выше доводами, то вы тоже считаете, что аннотации @FindBy не нужны, PageFactory не нужна. И инифиализировать пэдж-обжект нужно только с помощью конструктора:

MyPage page = new MyPage();

Никаких фабрик, аннотаций и другой чёртовой магии. Она точно добавляет сложности и точно не решает никаких проблем.

А если уж по чесноку, я думаю, что пэдж обжекты вообще не нужны. Но об этом отдельная статья.

Автоматизируйте с умом, други, и не забывайте главное правило из книжки “Design patterns”:

Объект - это не данные и операции с ними (как учат в школе).
Объект - это поведение.

Андрей Солнцев

asolntsev.github.io

Что на самом деле нельзя хардкодить

2016-07-08T00:00:00+00:00

Хардкод

Это страшное слово - хардкод. Все боятся это сделать, но иногда каждый из нас это делает.

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

Так что же на самом деле нельзя хардкодить?

Классический хардкод

Все обычно считают, что

Нельзя хардкодить числа в коде! Надо вынести в константу.
Нельзя хардкодить настройки в коде! Надо вынести в файл с настройками (а у некоторых и в базу данных).

То есть если джуниор девелопер напишет в коде if (age >= 23), ему за это надо дать по рукам. Так обычно считается. Чтобы сберечь руки, он должен срочно вынести “23” в константу типа MINIMUM_LOAN_AGE.

Давайте разбираться в причинах

А почему плохо прописать в коде “23”?

Обычно называют две причины. Их втирают нам в сознание ещё с университетской скамьи.

Когда нужно будет поменять “23” на “24”, её придётся поменять во многих файлах - трудоёмко.
Само по себе “23” плохо читается. Что означает “23” - возраст, длину волос, объём бензобака? Почему именно 23, а не 22 или 24?

Почему эти причины не катят?

Эти причины настолько нам привычны, что мы даже не задумываемся, насколько они актуальны в наше время. Вы удивитесь, но не очень-то актуальны. Прямо скажем, они устарели. Смотрите сами.

Во всех современных IDE очень легко поменять “23” на “24”. Одной кнопкой. Ctrl+R -> Enter. Всё. Хоть у тебя в проекте три файла, хоть три миллиона.
Да, “23” плохо читается. Но часто при вынесении в константу оно не становится более читаемым. Да, название константы MINIMUM_LOAN_AGE говорит о том, что это минимальный возраст, с которого можно брать кредит. Но и выражение if (age >= 23) в методе canRequestLoan() говорит ровно о том же ничуть не хуже.

А почему именно 23, почему не 22 или 24 - это всё равно непонятно. Чтобы это узнать, в наше время легче заглянуть в историю изменений (git -> annotate) или в тесты (Ctrl+Shift+T) - с нашими IDE это легко.

Ладно, ладно

Я знаю, вас переполняют эмоции. Вы хотели бы вбить мне в грудь осиновый кол за такую ересь. Но потерпите, сейчас мы дойдём до главного.

Конечно, всё-таки выносить такие штуки в константы иногда полезно.

НО

Я хотел сказать, что самый страшный хардкод - это вовсе не константы.

А что же - самый страшный хардкод?

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

Но вглядитесь, неужели это действительно самое страшное место? Оглядитесь вокруг, не притаилось ли рядом что-то более опасное? На самом деле самая страшная часть - это вот:

Потому, что вот её-то поменять во всём коде на порядок сложнее. Когда однажды выяснится, что для получения кредита нужно стать старше 23 лет, да ещё и найти работу, нам придётся найти в коде все места, где прописано if (age >= 23) и поменять их на if (age > 23 && employed). Но как найти все знаки все знаки >=? Их же тысячи! Вот это ручная работа на столетия!

Но самое страшное, что в коде могут быть и выражения вида

if (!(age < 23)), и
if (23 > age),

и даже такие места, которые совсем нереально обнаружить:

if (age < 23) {
  // 100500 строк кода
}
else {
  // можно получить кредит
}

Что же делать?

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

Например, так:

class User {
  public boolean canRequestLoan() {
    return age >= 23;
  }
}

И все остальные места должны использовать этот метод. Кажется тривиальным? О нет. Если это знание действительно в одном месте, зачем вы так рьяно хотите вынести “23” в константу?

Упростим

Всё ещё кажется тривиальным? Ок, давайте упростим пример. Забудьте 23. Пусть будет 0.

Я уверен, в вашем коде миллион таких мест:

  if (account.balance > 0) {
    // могу сделать платёж
  }

И я таких видел миллион. if balance > 0 прописан и на странице платежей, и на странице кредитов, и депозитов, и т.д.

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

  if (account.balance > 0 && !account.arrested) {
    // могу сделать платёж
  }

Но тут… опачки. Оказывается, что в десяти местах прописано if (balance > 0), в ещё двадцати - if (balance <= 0), а в грёбаном яваскрипте и вовсе if (account.balance).

И вот тут-то начинаются проблемы. Все эти места нужно анализировать отдельно. В некоторые из них нужно добавить && !arrested, а в некоторые не нужно - ведь там речь идёт не о платежах.

Я не придумываю, это абсолютно реальный пример.

Юнит-тесты

Очевидный плюс вынесения логики в методы - её легко тестировать.

Поначалу этот тест кажется даже избыточным и даже бесполезным:

  public class AccountTest {
    @Test public void canMakePaymentIfHasMoney() {
      assertTrue(new Account(1).canMakePayment());
      assertFalse(new Account(-1).canMakePayment());
    }
  }

Но всё меняется, как только добавляются ньвые требования:

  public class AccountTest {
    @Test public void canMakePayment_ifHasMoney_and_notArrested() {
      assertTrue(new Account(1, false).canMakePayment());
    }
    @Test public void cannotMakePaymentIfHasNoMoney() {
      assertFalse(new Account(-1, false).canMakePayment());
    }
    @Test public void cannotMakePaymentIfArrested() {
      assertFalse(new Account(1, true).canMakePayment());
    }
  }

Пэдж обжекты

Всё ещё кажется, что для разумных людей это очевидные вещи?

Тогда посмотрите на пэдж обжекты - воплощение константного антипаттерна во всей красе! Миллионы людей выносят локаторы в константы и даже не задумываются, что что-то здесь не так…

Андрей Солнцев

asolntsev.github.io

Как Java8 может помочь в написании юнит-тестов

2016-04-11T00:00:00+00:00

Проблема

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

И вот тут неожиданно на помощь приходит Java 8! Казалось бы, при чём тут?

А вот при чём.

Как решается сейчас

Допустим, есть у вас класс Employee:

public class Employee {
  public String firstName;
  public String lastName;
  public Date birthDate;
  public String birthPlace;
  public Gender gender;
}

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

Как создавать кучу таких разных объектов в тестах?

Обычно есть четыре варианта, и все они не очень.

Вариант 1: засилье конструкторов

Создаётся куча разных конструкторов на все случаи жизни.

public Employee(String lastName) {
  this(null, lastName, null, null, null);
}

public Employee(Date birthDay, String birthPlace) {
  this(null, null, birthDay, birthPlace, null);
}

и так далее.

Минус этого решения понятен: слишком много конструкторов. Учитывая, что используются они только в тестах - сомнительная идея…

Вариант 2: засилье `null`

Второй вариант - иметь один “общий” конструктор со всеми возможными параметрами. Тогда ваши тесты превращаются в кучу “null” через запятую:

@Test public void test1() {
  new Employee(null, "Smith", null, null, null);
}

@Test public void test2() {
  new Employee(null, new Date(11, 11, 2011), "Happiness", null);
}

Минус и тут очевиден: такие тесты плохо читаются. Непонятно, “Happiness” - это какое именно поле? Фамилия? Место предыдущей работы? Место отсидки? Ожидания от работы? Приходится заглядывать внутрь, чтобы понять. IDE, конечно, чуть облегчают эту задачу, но всё же.

Да, и есть ещё один минус. Когда ты захочешь добавить новое поле в этот класс, придётся перешерстить огромную кучу существующих тестов. IDE облегчают и эту задачу, но всё же.

Вариант 3: засилье вспомогательных методов

Можно ещё плодить в тестах вспомогательные методы-фабрики для создания нужных объектов:

public void GenderTest {
  private static Employee withBirthdate(Date birthDate, String birthPlace) {...}
  private static Employee withGender(Gender gender) {...}
}

Это вполне себе нормальный вариант. Но всё-таки приходится писать много вспомогательного кода, и часто такие методы дублируются в разных тестах.

Вариант 4: засилье билдеров

Все любят паттерны. Паттерны-фигаттерны. Паттерн “билдер” не исключение. Его часто советуют.

  @Test public void test1() {
    Employee employee = Employee.builder()
      .withFirstName("john")
      .withLastName("Smith")
      .withGender(MALE)
      .build();
  }

Выглядит красиво, но на самом деле многовато усилий ради тестов, не? Кода для билдеров придётся написать довольно прилично.

Наверное, есть даже библиотеки, автоматизирующие создание билдеров. Это здорово. Но есть вариант проще - Java 8 предлагает решение из коробки.

И что же даст Java 8?

В Java 8 появились лямбды. Никто не знает, зачем они нужны, но типа круто. Так вот теперь настало время лямбд - от них появилась реальная польза!

Смотрите, как теперь можно создавать объекты в тестах:

  @Test public void test1() {
    Employee employee = new Employee(e -> e.lastName = "Smith");
  }

  @Test public void test2() {
    Employee employee = new Employee(e -> {
      e.birthDate = dateX; 
      e.birthPlace = "PlaceX";
    });
  }

Каждый тест хорошо читается. Видно, какие поля проставляются, не нужно лезть в дебри конструктора.

И для этого не надо писать кучу конструкторов, вспомогательных методов или билдеров. Нужен всего-навсего один конструктор:

public Employee(Consumer<Employee> builder) {
  builder.accept(this);
}

И всё! Тесты читаемые, лишнего кода почти ноль.

Будущее уже здесь, йо.

Андрей Солнцев

ru.selenide.org

How Java8 can help in writing unit-tests

2016-04-11T00:00:00+00:00

Problem

Typically you need to create a lot of various objects with various states in your tests. But you don’t always have appropriate constructors, and probably don’t want to have too many constructors.

And Java 8 can help here!

How you solve it now

Let’s suppose that you have a class Employee:

public class Employee {
  public String firstName;
  public String lastName;
  public Date birthDate;
  public String birthPlace;
  public Gender gender;
}

In some tests you want to set only name, in others - only birthday, sometimes only gender. In most tests, you want to set different combinations of data.

How to create so much different objects in tests?

Typically we have four options, all of which are not very good.

Option 1: lot of constructors

You create a lot of constructors for different data sets.

public Employee(String lastName) {
  this(null, lastName, null, null, null);
}

public Employee(Date birthDay, String birthPlace) {
  this(null, null, birthDay, birthPlace, null);
}

etc.

It’s obvious why this is not a very good solution: too many constructors. You probably don’t want to have too many constructors, especially if you only use them in tests.

Option 2: lot of `null`s

The next option is to have one “common” constructor with all possible parameters. In this case your tests soon become to a mass of comma-separated “nulls”:

@Test public void test1() {
  new Employee(null, "Smith", null, null, null);
}

@Test public void test2() {
  new Employee(null, new Date(11, 11, 2011), "Happiness", null);
}

Again, it’s obviously not very good. What’s exactly “Happiness” - what field is it? Is it family name? First name? Previous employer? Job expectations? You need to dive into the constructor to understand. IDE helps somewhat, but…

This solution has one more problem. When you add new field to this class, you will need to refactor many-many existing tests. IDE helps somewhat, but still…

Option 3: lot of helper methods

You can also create plenty of helper factory methods for creating objects:

public void GenderTest {
  private static Employee withBirthdate(Date birthDate, String birthPlace) {...}
  private static Employee withGender(Gender gender) {...}
}

It’s not a bad option. But you still need to write a lot of assistance code, and such methods are often duplicated among tests.

Option 4: the desolation of builders

We all love patterns. We all love builders. It’s recommended quite often.

  @Test public void test1() {
    Employee employee = Employee.builder()
      .withFirstName("john")
      .withLastName("Smith")
      .withGender(MALE)
      .build();
  }

It look pretty good.

But isn’t it too much helper code just for tests? Yes, you need to write quite a lot of code for builder pattern.

There probably are some libraries that can generate builders. That’s good. But we have simpler option: Java 8 suggests a solution out-of-the-box.

So how Java 8 will solve this?

Java 8 brings lambdas. Nobody knew why it’s cool, but everybody thought that it’s cool. Now it’s time for lambdas! Now we will see why they can be useful.

Look how you can create objects in tests - using lambdas:

  @Test public void test1() {
    Employee employee = new Employee(e -> e.lastName = "Smith");
  }

  @Test public void test2() {
    Employee employee = new Employee(e -> {
      e.birthDate = dateX; 
      e.birthPlace = "PlaceX";
    });
  }

Such tests are pretty well readable. You see what fields are initialized. You don’t need to dive into constructor.

You don’t need to write lot of constructors, builders or any other assistance code. You just need the only constructor:

public Employee(Consumer<Employee> builder) {
  builder.accept(this);
}

That’s it! You get pretty readable tests with almost zero investment.

Future is already here.

Andrei Solntsev

selenide.org

Эффективные UI-тесты на Selenide

2015-12-31T00:00:00+00:00

В ожидании чудес

Канун Нового Года - время чудес. В преддверии нового года мы все вспоминаем год уходящий и строим планы на следующий. И надеемся, что все проблемы останутся в прошлом, а в новом году случится чудо, и мы заживём по-новому.

Какой же Java разработчик не мечтает о чуде, которое осенит его и позволит стать Самым Крутым На Свете Java Программистом.

Хорошие новости: я хочу рассказать как раз о таком чуде.

Имя ему - автоматические тесты!

Фу, тесты?

Да. Настоящим мастером своего дела вас сделают не чудо-фреймворки, не микро/пико/нано сервисы, а дисциплина. Дисциплина, которая говорит, что программист может считать дело законченным не тогда, когда код готов, а тогда, когда к нему написаны и запущены автоматические тесты. И если с юнит-тестами всё более-менее ясно, то UI-тесты пока остаются для разработчиков тёмным лесом.

Да ну, это же нудно?

О нет, поверьте мне! Написание грамотных автотестов - это отличный челлендж, тут есть над чем пораскинуть мозгами. И это может быть очень весело и интересно. Только надо использовать правильные инструменты.

Правильный инструмент для написания UI-тестов - это:

Selenide

Selenide - это библиотека для написания лаконичных и стабильных UI тестов с открытым исходным кодом.

Selenide - идеальный выбор для разработчиков, потому что у неё очень низкая кривая обучения. Вам не придётся заморачиваться со всеми этими техническими подробностям, на которые обычно тестировщики-автоматизаторы тратят так много времени: нюансы работы с браузерами, типичные проблемы с таймингом и аяксом.

Посмотрим, как выглядит простенький тест на Selenide:

public class GoogleTest {
  @Test
  public void user_can_search_everything_in_google() {
    open("http://google.com/ncr");
    $(By.name("q")).val("selenide").pressEnter();

    $$("#ires .g").shouldHave(size(10));

    $("#ires .g").shouldBe(visible).shouldHave(
        text("Selenide: concise UI tests in Java"),
        text("selenide.org"));
  }
}

(естественно, вместо Google здесь будет ваше веб-приложение)

Что здесь происходит?

Вы открываете браузер всего-навсего одной командой open(url)
Вы ищете элемент на странице командой $.
Вы можете найти элемент по имени, ID, CSS селектору, атрибуту, xpath и даже по тексту.
Вы совершаете некие действия с элементом: в данном случае вводите текст командой val() и нажимаете ввод с помощью команды pressEnter().
Вы проверяете результат: ищете все результаты поиска с помощью $$ (она возвращает коллекцию элементов). Вы проверяете размер и содержимое коллекции.

Этот тест легко читается, не правда ли?
Этот тест легко пишется, не правда ли?

А главное, этот тест легко запускается. Убедитесь сами:

Selenide Harlem Shake from Selenide on Vimeo.

Погружаемся глубже

Конечно, в жизни не всё так просто. Написание автотестов подразумевает кучу проблем, ведь не зря разработчики так их боятся - больше, чем любого наисложнейшего фреймворка или технологии.

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

Давайте рассмотрим типичные проблемы UI-тестов подробнее.

Проблемы с аяксом и таймаутами

В наше время веб-приложения все сплошь динамические. Каждый кусочек приложения может быть нарисован/изменён динамически в любой момент времени. Это создаёт проблемы для автоматических тестов. Тест, который ещё вчера был зелёным, может внезапно стать красным безо всяких изменений в коде. Просто потому, что браузер сегодня встал не с той ноги и запустил вон тот javascript чуточку медленнее, и тест успел кликнуть кнопочку раньше, чем она до конца отрисовалась.

Это прям вечная проблема у всех. Поэтому автоматизаторы пихают везде “слипы”.

Тем более удивительно, насколько простым и надёжным способом Selenide решает эту проблему.

Если коротко, в Selenide каждый метод умеет немножко подождать, если надо. Люди называют это “умными ожиданиями”.

Когда вы пишете

$("#menu").shouldHave(text("Hello"));

Selenide проверит, существует ли элемент с ID=”menu”. И если нет, Selenide чуть-чуть подождёт, проверит ещё. Потом ещё подождёт. И только когда элемент появится, Selenide проверит, что у него нужный текст.

Конечно, нельзя ждать вечно. Поэтому Selenide ждёт не больше 4 секунд. Естественно, этот таймаут можно настраивать.

Не сделает ли это мои тесты медленными?

Нет, не сделает. Selenide ждёт, только если надо. Если элемент изначально присутствует на странице - Selenide не ждёт. Если элемент появился через 300 мс - Selenide ждёт только 300 мс. Это именно то, что вам нужно.

Множество встроенных проверок

А что ещё вы можете проверять на странице, помимо текста? Довольно много всего.

Например, вы можете проверить, что элемент видимый (visible). Если пока нет, Selenide подождёт до 4 секунд.

$(".loading_progress").shouldBe(visible);

Вы можете даже проверить, что элемент не существует. Если элемент всё же найден, Selenide предположит, что он вот-вот пропадёт и подождёт до 4 секунд.

$(By.name("gender")).should(disappear);

Вы можете делать несколько проверок в одной строке (т.н. “fluent API” и “method chain”), что сделает ваши тесты ещё более лаконичными:

$("#menu")
  .shouldHave(text("Hello"), text("John!"))
  .shouldBe(enabled, selected);

Коллекции

Selenide позволяет вам очень удобно работать с коллекциями элементов. Вы можете проверять сразу множество элементов в одной строке.

Например, вы можете проверить, что на странице ровно N таких-то элементов:

$$(".error").shouldHave(size(3));

Вы можете отфильтровать подмножество элементов:

$$("#employees tbody tr")
  .filter(visible)
  .shouldHave(size(4));

Вы можете проверить тексты элементов. В большинстве случаев этого достаточно, чтобы проверить целую таблицу или строку в таблице:

$$("#employees tbody tr").shouldHave(
  texts(
      "John Belushi",
      "Bruce Willis",
      "John Malkovich"
  )
);

Скачивание/закачивание файлов

С Selenide закачивать файлы предельно просто:

$("#cv").uploadFile(new File("cv.doc"));

И вы даже можете закачать несколько файлов разом:

$("#cv").uploadFile(
  new File("cv1.doc"),
  new File("cv2.doc"),
  new File("cv3.doc")
);

И скачивание файлов тоже крайне просто:

File pdf = $(".btn#cv").download();

Тестирование “динамичных” веб-приложений

Некоторые веб-фреймворки (такие как GWT) генерируют совершенно нечитаемый HTML, не поддающийся анализу. Там нет постоянных ID, имён или классов.

Это прям вечная проблема у всех. Поэтому автоматизаторы пихают везде длиннющие “xpath” и вынуждены их поддерживать до конца жизни.

Чтобы решить эту проблему, Selenide предлагает искать элементы по тексту.

import static com.codeborne.selenide.Selectors.*;

$(byText("Привет, октябрята!"))             // находит элемент по тексту целиком
   .shouldBe(visible);

$(withText("тябр"))                         // находит элемент по подстроке
   .shouldHave(text("Привет, октябрята!"));

Вопреки распространённому мнению, поиск элементов по тексту - не такая уж плохая идея. Между прочим, именно так ищет элементы реальный пользователь. Он не ищет элементы по ID или классу, и уж тем более не по XPATH. Он ищет по тексту. (ну, ещё по цвету, но это труднее поддаётся автоматизации).

Ещё в Selenide есть несколько полезных методов для поиска дочерних или родительских элементов. Это позволяет вам навигировать между элементами без опознавательных знаков.

$("td").parent()
$("td").closest("tr")
$(".btn").closest(".modal")
$("div").find(By.name("q"))

Например, вы можете найти ячейку в таблице по тексту, затем найти содержащую её строку tr и найти в этой строке кнопку “Save”:

$("table#employees")
  .find(byText("Joshua"))
  .closest("tr.employee")
  .find(byValue("Save"))
  .click();

PageObject

Когда один и тот же элемент или страница используется во многих тестах, имеет смысл вынести логику страницы в отдельный класс. Такой класс называется Page Object, и их тоже очень удобно делать с Selenide.

Приведённый выше пример гугла можно переделать на page object таким образом:

  @Test
  public void userCanSearch() {
    GooglePage page = open("http://google.com/ncr", GooglePage.class);
    SearchResultsPage results = page.searchFor("selenide");
    results.getResults().shouldHave(size(10));
    results.getResult(0).shouldHave(text("Selenide: concise UI tests in Java"));
  }

Page Object для страницы поиска гугл:

public class GooglePage {
  public SearchResultsPage searchFor(String text) {
    $(By.name("q")).val(text).pressEnter();
    return page(SearchResultsPage.class);
  }
}

И для страницы результатов поиска:

public class SearchResultsPage {
  public ElementsCollection getResults() {
    return $$("#ires .g");
  }
  public SelenideElement getResult(int index) {
    return $("#ires .g", index);
  }
}

Но хочу обратить ваше внимание, что UI-тестов должно быть мало. По той простой причине, что это всё-таки браузер, аякс, javascript, а всё это сравнительно медленно и нестабильно. Напишите один-два UI-теста, которые проверят, что приложение в целом работает: страничка открывается, текст отрисовывается, кнопки нажимаются, JavaScript не грохается.

А всевозможные комбинации и редкие случаи обязательно проверяйте с помощью модульных тестов.

Типичная ошибка - проверять всё через UI. Этим особенно страдают тестировщики в тех компаниях, где разработчики не пишут модульных тестов. Бедным тестировщикам просто ничего не остаётся, кроме как городить огромную неповоротливую кучу медленных и нестабильных UI-тестов и впрягаться в их пожизненную поддержку.

Но ты ж программист! Не заставляй людей мучаться.

… и много других полезняшек

В Selenide есть ещё много функций, таких как:

$("div").scrollTo();
$("div").innerText();
$("div").innerHtml();
$("div").exists();
$("select").isImage();
$("select").getSelectedText();
$("select").getSelectedValue();
$("div").doubleClick();
$("div").contextClick();
$("div").hover();
$("div").dragAndDrop()
zoom(2.5);
...

мы не сможем их все здесть описать. Но хорошая новость в том, что вам не нужно всё это запоминать. Просто наберите $, точку и начните писать примерно, что вы хотите. Например “val” или “enter”. И посмотрите, какие варианты предложит ваша IDE.

Используйте мощь IDE! Не засоряйте голову деталями и сконцентрируйтесь на бизнес-логике.

Сделаем мир лучше

У верю, что мир станет лучше, когда все разработчики будут писать автоматические тесты для своего кода. Когда разработчики будут спокойно вставать в 17:00 и идти к своим детям, не боясь, что они что-то сломали своими изменениями.

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

Давайте сделаем мир лучше с помощью автоматических тестов! Будьте уверены в своём софте, и вам не придётся скрещивать пальцы на удачу перед каждым релизом.

С Новым Годом!

Андрей Солнцев

ru.selenide.org

Effective UI tests with Selenide

2015-12-31T00:00:00+00:00

Waiting for miracles

Christmas is a time for miracles. On the eve of the new year we all build plans for the next. And we hope that all problems will leave in the ending year, and a miracle happens in the coming year.

Every Java developer dreams about a miracle that lets him become The Most Effective Java Developer in the world.

I want to show you such a miracle.

It’s called automated tests!

Ugh, tests?

Yes. You will not become a real master thanks to micro/pico/nano services. You will become a real master thanks to discipline. Discipline claiming that developer only then reports jobs as done when code and tests are written and run.

But, isn’t testing boring?

Oh no, believe me! Writing of fast and stable automated tests is a great challenge for smartest heads. And it can be very fun and interesting. You only need to use right tools.

The right tool for writing UI tests is:

Selenide

Selenide is an open-source library for writing concise and stable UI tests.

Selenide is an ideal choice for software developers because it has a very low learning curve. Thus, you don’t need to bother with browser details, all these typical ajax and time issues that eat most of QA automation engineers’ time.

Let’s look at a simplest Selenide test:

public class GoogleTest {
  @Test
  public void user_can_search_everything_in_google() {
    open("http://google.com/ncr");
    $(By.name("q")).val("selenide").pressEnter();

    $$("#ires .g").shouldHave(size(10));

    $("#ires .g").shouldBe(visible).shouldHave(
        text("Selenide: concise UI tests in Java"),
        text("selenide.org"));
  }
}

(Of course, you will test your web application instead of Google).

Let’s look closer what happens here.

You open a browser with just one command open(url)
You find an element on a page with command $.
You can find element by name, ID, CSS selector, attributes, xpath and even by text.
You manipulate the element: enter some text with val() and press enter with (surprise-surprise!) pressEnter().
You check the results: find all found results with $$ (it returns a collection of all matched elements). You check the size and content of the collection.

Isn’t this test easy to read?
Isn’t this test easy to write?

I believe it is.

And it’s easy to run, look at this:

Selenide Harlem Shake from Selenide on Vimeo.

Deeper into details

Of course, real life is never that simple. Writing autotests means a lot of problems, that’s why developers are afraid of tests more than of any complex framework or technology.

The good news is that Selenide resolves most of these problems.

Let’s consider typical problems of UI-tests.

Ajax/timing problems

Nowdays web applications are dynamic. Every single piece of application can be rendered/changed dynamically at any moment. This creates a lot of problems for automated tests. Test that is green today can suddenly become red at any moment, just because browser executed some javascript a little bit longer than usual.

It’s a real pain in the ajjaxx.

Quite unbelievably, but Selenide resolves most of the these problems in a very simple way.

Simply said, every Selenide method waits a little bit if needed. People call it “smart waiting”.

When you write

$("#menu").shouldHave(text("Hello"));

Selenide checks if the element exists and contains text “Hello”.

If not yet, Selenide assumes that probably the element will be updated dynamically soon, and waits a little bit until it happens. The default timeout is 4 seconds, which is typically enough for most web applications. And of course, it’s configurable.

Doesn’t it make my tests slow?

No, it doesn’t. Selenide waits only when it’s needed. If element is already visible on the page - Selenide will not wait. If element appears after 300 ms - Selenide will only wait for 300 ms. That’s perfectly what you need.

Rich set of matchers

You can check pretty much everything with Selenide. Using “smart waiting” mechanism mentioned above.

For example, you can check if element exists. If not yet, Selenide will wait up to 4 seconds.

$(".loading_progress").shouldBe(visible);

You can even check that element does not exist. If it still exists, Selenide will wait up to 4 seconds until it disappears.

$(By.name("gender")).should(disappear);

And you can use fluent API and chain methods to make your tests really concise:

$("#menu")
  .shouldHave(text("Hello"), text("John!"))
  .shouldBe(enabled, selected);

Collections

Selenide allows you to work with collections, thus checking a lot of elements with one line of code.

For example, you can check that there are exactly N elements on a page:

$$(".error").shouldHave(size(3));

You can find subset of collections:

$$("#employees tbody tr")
  .filter(visible)
  .shouldHave(size(4));

You can check texts of elements. In most cases, it’s sufficient to check the whole table or table row:

$$("#employees tbody tr").shouldHave(
  texts(
      "John Belushi",
      "Bruce Willis",
      "John Malkovich"
  )
);

Upload/download files

It’s pretty easy to upload a file with Selenide:

$("#cv").uploadFile(new File("cv.doc"));

You can even upload multiple files at once:

$("#cv").uploadFile(
  new File("cv1.doc"),
  new File("cv2.doc"),
  new File("cv3.doc")
);

And it’s unbelievably simple to download a file:

File pdf = $(".btn#cv").download();

Testing “highly dynamic” web applications

Some web frameworks (e.g. GWT) generate HTML that is absolutely unreadable. Elements do not have constant IDs or names.

It’s a real pain in the xpathh.

Selenide suggests to resolve this problem by searching elements by text.

import static com.codeborne.selenide.Selectors.*;

$(byText("Hello, Kitty!"))             // find by the whole text
   .shouldBe(visible);

$(withText("itt"))                     // find by substring
   .shouldHave(text("Hello, Kitty!"));

Searching by text is not bad idea at all. In fact, I like it because it emulates behaviour of real user. Real user doesn’t find buttons by ID or XPATH - he finds by text (or, well, color).

Another useful set of Selenide methods allows you to navigate between parents and children.

$("td").parent()
$("td").closest("tr")
$(".btn").closest(".modal")
$("div").find(By.name("q"))

For example, you can find a table cell by text, then by its closest tr descendant and find a “Save” button inside this table row:

$("table#employees")
  .find(byText("Joshua"))
  .closest("tr.employee")
  .find(byValue("Save"))
  .click();

… And many other functions

Selenide has many more functions, like:

$("div").scrollTo();
$("div").innerText();
$("div").innerHtml();
$("div").exists();
$("select").isImage();
$("select").getSelectedText();
$("select").getSelectedValue();
$("div").doubleClick();
$("div").contextClick();
$("div").hover();
$("div").dragAndDrop()
zoom(2.5);
...

but the good news is that you don’t need to remember all this stuff. Just put $, put dot and choose from available options suggested by your IDE.

Use the power of IDE! Concentrate on business logic.

Make the world better

I believe the World will get better when all developers start writing automated tests for their code. When developers will get up at 17:00 and go to their children without fearing that they broke something with last changes.

Let’s make the world better by writing automated tests!

Deliver working software.

Andrei Solntsev

selenide.org

Почему IDEA лучше Eclipse

2012-12-12T00:00:00+00:00

Священный спор

Принято считать, что есть «вечные» вопросы, на которые нет правильного ответа. Например, что лучше: Windows или Linux, Java или C#; Чужой против Хищника или Чак Норрис против Ван Дамма.

Одним из таких холиваров считается выбор лучшей IDE для Java.

Идут постоянные споры о том, в которой из них больше плагинов, горячих клавиш и т.д. Различий так много, что трудно выбрать, какие из них важнее, и все сходятся в одном: обе IDE примерно одинаковы по своим возможностям, и выбор одной из них — это дело вкуса.

Так вот, я утверждаю, что это не просто дело вкуса. Есть объективные причины, почему

Intellij IDEA (как Java IDE) однозначно лучше, чем Eclipse.

Подчёркиваю, мы сейчас рассматриваем обе среды именно как Java IDE.

Я не буду приводить кучу мелких различий вроде плагинов, горячих клавиш и т.п. — этому посвящены многие страницы в интернете, например, эта: часть 1, часть 2, часть 3.

Объясню лишь одно, самое главное отличие. Как правило, о нём не знают ни идеяшники, ни эклипсофилы, ибо первые привыкли к нему и не знают, что в других IDE этого может и не быть, а вторые привыкли жить без него, и даже не догадываются, что может быть лучше. Более того, эклипсники его не замечают, когда пробуют IDEA ради интереса, ибо привыкли работать по-старому.

Откуда такая уверенность?

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

Я работал на Eclipse лет 5, знал её очень хорошо, писал под неё плагины, и искренне любил её. Потом я перешёл в другую компанию, и был вынужден пересесть на IDEA. Пережив серьёзную ломку, я наконец понял, чем же IDEA круче. И вот уже пару лет работаю на IDEA. Поэтому я знаю, что говорю.

Основное различие между IDEA и Eclipse

Главная вещь, отличающая IDEA — она понимает контекст. Именно это имеют в виду сотрудники JetBrains, когда называют её «интеллектуальной» (intelligent). Что это значит? IDEA индексирует весь ваш проект, анализирует всё, что в нём есть, и даже строит синтаксическое дерево. Благодаря этому IDEA в любой момент, куда бы вы ни поставили курсор, знает, где мы находимся и что тут можно делать.

Непонятно? Ещё бы. Ничего, на примерах станет ясно.

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

1. Отладка

Чтобы при отладке увидеть значение какого-то выражения, в Eclipse необходимо сначала выделить это выражение. Причём выделить точно, случайно выделите лишний символ — Eclipse не поймёт. После этого жмём Ctrl+Shift+I и видим значение выражения.

В IDEA же ничего выделять не надо, достаточно просто поставить курсор в нужное место (в данном случае на методе hasAttribute) и нажать Alt+F8. IDEA сама поймёт, какое выражение вам, вероятно, нужно, и тут же откроет диалог, где вы сможете редактировать выражение и сразу видеть его значение:

Выходит, обе IDE в принципе позволяют делать одно и то же. Но в IDEA это намного удобнее и быстрее. Я серьёзно, разница огромная — это просто небо и земля. В этом маленьком окошке IDEA сделает вам и автозаполнение, и подсветку синтаксиса, и всё на свете.

2. Автозаполнение (autocomplete)

Автозаполнение — это то, что выгодно отличает любую IDE от notepad. И в этой области «понимание контекста» даёт IDEA качественное преимущество. Допустим, мы начали писать строчку кода:

assertElement(By.id("errorMessage"), vi

И тут мы хотим узнать, какие у нас есть варианты, чего там может начинаться с букв «vi».

Что делает IDEA? Не дожидаясь никаких нажатий клавиш, она сразу же понимает, что метод assertElement хочет получить вторым параметром объект класса Condition, а в этом классе как раз есть статическая переменная типа Condition с именем visible. И предлагает единственный возможный вариант:

А что делает Eclipse? Увы, он не понимает контекста. Он не знает, что курсор находится на месте второго параметра метода assertElement. Поэтому, когда вы нажимаете заветные Ctrl+Space, Eclipse тупо показывает всё, что есть в природе, что начинается на буквы «vi»:

В красивом всплывающем окошке мы видим много-много красиво подсвеченной хорошо задокументированной бесполезной информации… :(

3. Рефакторинг

Профессиональные программисты умеют быть продуктивными, используя для изменения кода те рефакторинги, которые предлагает их IDE. Все современные IDE в принципе предлагают весьма впечатляющий набор рефакторингов, наверное, даже большинство программистов не знает и не использует все из них. Но опять же, рефакторинги в IDEA интеллектуальные. Они догадываются, чего вы хотите, и предлагают разные варианты, которые в большинстве ситуаций подходят.

Например, есть у нас метод assertErrorMessageIsHidden:

public void assertErrorMessageIsHidden() {
    assertElement(By.id("errorMessage"), Condition.visible);
  }

И мы хотим сделать так, чтобы строка «errorMessage» приходила в метод как параметр.

Начнём с IDEA. Ставим курсор на любое место в строке «errorMessage», нажимаем заветные Ctrl+Alt+P (от «parameter»), и IDEA подсказывает, какое выражение мы могли бы вынести в параметр:

Как только выражение «errorMessage» выбрано, IDEA подсказывает несколько возможных имён для этого параметра.

Вы будете ещё не раз удивлены тем, как умно себя ведёт IDEA, предлагая свои варианты для имени чего-либо. Она учитывает и название метода, и тип переменной, и значение, и названия подобных переменных в других местах, и те названия, которые вы давали подобным переменным раньше — разве что ваш знак зодиака не учитывается. Правда-правда, не проходит и месяца, чтобы я не сказал фразы: «Ого, IDEA и это умеет?»

Ну и посмотрим, что нам предложит Eclipse.

Не забываем: выделяем выражение «errorMessage» (обязательно с кавычками, иначе получите дикое сообщение «An expression must be select to activate this refactoring»), выбираем рефакторинг «Introduce parameter» (из меню, горячей клавиши нет), и получаем тот же результат. Правда, никаких вариантов для имени параметра Eclipse не предлагает, но и на том спасибо.

Выводы

Если мы говорим о Java IDE, то IDEA круче Eclipse. Это не просто дело вкуса. IDEA объективно лучше. Она позволяет быстрее и качественне писать и менять код, подсказывает подходящие имена, находит подходящие методы. Не требует точно выделить выражение, а по тому, где вы находитесь, угадывает, что вы хотели сделать и как хотели это назвать. IDEA предугадывает и подсказывает.

P.S. Оговорки

Оговорюсь: IDEA лучше Eclipse в качестве Java IDE. Если вы рассматриваете их в каком-то другом качестве — например, как IDE для другого языка (C++, Python, Scala), или как платформу для построения Desktop-приложений, то Eclipse вполне может победить.

В общем-то, это вытекает и из определения. Eclipse позиционирует себя как абстрактная платформа для построения чего бы то ни было (с помощью дописывания плагинов), а IDEA позиционирует себя как «интеллектуальная IDE для Java». Так оно и есть.

Интереса ради попробую назвать аспекты, в которых Eclipse, возможно, круче IDEA:

Eclipse красивее. Вся эта суета вокруг SWT и нативных контролов стоила того. Eclipse выглядит как солидное приложение с продуманными шрифтами и иконками, в то время как IDEA на первый взгляд выглядит как наколенная поделка с ламерскими иконками и нелепым свинговским интерфейсом.
В Eclipse богаче поддережка структуры проекта. В IDEA есть проект, состоящий из модулей, а в Eclipse есть workspace, состоящий из проектов, но их можно ещё и закрывать/открывать, объединять в группы и прятать.
Для Eclipse вроде бы проще писать плагины.
В конце концов, Eclipse бесплатен. Впрочем, бесплатной версии IDEA мне хватает за глаза, ведь я использую запускалку для разработки веб-приложений.

Итогошки

Если вам нужны красивые иконки, платформа для создания настольных приложений, или IDE для C++, то Eclipse, вероятно, предпочтительнее. Если же вы серьёзный Java-программист, и вам нужна среда, позволяющая быстро и удобно вести разработку, сосредоточившись на проблеме и не отвлекаясь на средство разработки, то IDEA — это то, что нужно.

На этом, я надеюсь, один вечный спор можно считать законченным.

Кодьте с удовольствием!

Why IDEA is better than Eclipse

2012-12-12T00:00:00+00:00

Holy war

There are “eternal” questions that have no single correct answer. E.g. what is better: Windows or Linux, Java or C#; who is stronger, Chuck Norris or Van Damme. One of such holywars is selection of the best Java IDE.

There is a lot of disputes on this topic discussing which of them has more plugins, shortcuts and so on. There is so many differences that it’s difficult to decide what of them are the most important. As a result, people typically claim that both IDEs are equal in their capabilities, and choosing of one of them is a matter of taste.

I claim that it is not just a matter of taste. There are objective reasons why

Intellij IDEA (as a Java IDE) is definitely better than Eclipse.

I am not going to compare lot of tiny differences like plugins, shortcuts etc - there is a plenty of blog posts on this topic, like this one: part 1, part 2,
part 3. I am going to show just one major difference between IDEA and Eclipse. Typically, neither IDEA nor Eclipse fans know it. The first ones used to it and cannot imagine that IDE can miss it. The second ones used to live without it and cannot imagine that IDE can do such things. Moreover, Eclipse users typically don’t notice this difference when trying IDEA for fun, just because they used to work “in Eclipse mode”.

Why am i so confident?

Before I start, let me explain who I am and why is my opinion worth listening to.

I’ve been working on Eclipse for 5 years, I knew it very well, I wrote plugins for it and sincerely loved Eclipse. Then I switched to another company, and was forced to move to IDEA. After surviving a serious break-up, I finally realized why is IDEA steeper. And now I have been working on IDEA for a couple of years. So I know both IDEs well and can compare them.

The main difference between idea and eclipse

The main reason why IDEA is steeper is: IDEA feels context. That’s what JetBrains employees mean when they name IDEA intelligent. What it really means? IDEA indexes the whole your project, analyses everything it has, and even builds the syntax tree. Thanks to it, at any time, wherever you put the cursor, IDEA knows where you are and what can be done there.

Still not clear? Do not worry, it will become clear in the following examples.

This ability to understand the context is expressed in many, many ways, here are just a few.

1. Debugging

As a part of debugging process, we often want to evaluate some expression to see its value. In Eclipse you need to select this expression. It’s important to exactly select the whole expression, otherwise Eclipse cannot evaluate it. Now you press Ctrl+Shift+I and see the value of expression.

With IDEA you don’t need to select anything. You just put cursor at any place inside your expression (at method hasAttribute in given case) and press Alt+F8. IDEA understands which expression you probably need and shows a dialog window suggesting several possible variants for your expression. You can also edit and immediatelly evaluate the expression in this dialog. Very convenient! After trying this feature, you just cannot debug in Eclipse anymore.

It turns out that both IDEs, in principle, allow you to do the same thing. But with IDEA it’s much easier and faster. I’m serious, the difference is huge - it’s just Heaven and Earth. In this small dialog window IDEA will provide autofilling, syntax highlighting and everything you need.

2. Autocomplete

Autocomplete is what distinguishes any IDE from the notepad. In this area feeling the context gives IDEA a qualitative advantage. For example, we started writing a line of code:

assertElement(By.id("errorMessage"), vi

and now we want to find what options do we have: what can start with letters “vi”.

What IDEA does? Not waiting for any keystrokes, it immediately understands that method assertElement wants an Condition class instance as a second parameter, and there is a static variable in class Condition with name visible. And IDEA immediately suggests the only valid option:

And what Eclipse does? Alas, it does not understand the context. It does not know that the cursor is located where the second parameter of the method assertElement should place. So when you press the sacred Ctrl + Space, Eclipse simply shows everything in Universe that begins with the letters “vi”:

In a beautiful pop-up window we see a lot of pretty-highlighted well-documented useless information. :(

3. Refactoring

Professional programmers are able to be productive using refactorings provided by their IDE. All modern IDE offer a very impressive set of refactorings. But then again, IDEA refactorings are intelligent. They realize what you want, and offer different options that are suitable for most situations.

For example, suppose we have a method assertErrorMessageIsHidden:

public void assertErrorMessageIsHidden() {
    assertElement(By.id("errorMessage"), Condition.visible);
  }

And we want the String "errorMessage" to come as a parameter to this method.

Let’s start from IDEA. Put the cursor to any place inside the string “errorMessage”, press Ctrl+Alt+P (meaning “parameter”), and IDEA suggests what expression we probably could extract to a parameter:

As soon as the expression “errorMessage” is selected, IDEA suggests several possible names for this parameter.

Wow every month

You will be surprised many, many times at how smart behaves IDEA, offering options for the name of something. It takes into account method name, variable type and even value, and names of such variables in other places, and those names that you gave such a variable before - except that your zodiac sign is ignored. Believe me, you will say: “Wow, IDEA is able to do such thing too?” at least once every month.

And now let’s look that Eclipse suggests.

Do not forget: select the entire expression “errorMessage” (always with quotes, or get a wild message “An expression must be select to activate this refactoring”), choose a refactoring “Introduce parameter” (from the menu, there is no hot key) and get about the same result. However, Eclipse doesn’t suggest options for a parameter name, but thanks for that.

Conclusion

If we are choosing a Java IDE then Intellij IDEA is definitely better than Eclipse. It’s not just a matter of taste. IDEA is objectively better. It lets you to quickly and easily write and change the code, suggests appropriate names, finds the appropriate methods. It does not require you to exactly select the expressions, but guesses what you want to do and how you wanted to name it. IDEA anticipates and suggests.

P.S. Remarks

I claim that IDEA is better Eclipse just as a Java IDE. If you are considering them in some other capacity - such as the IDE for other languages (C++, Python, Scala), or as a platform for building desktop application, Eclipse may very well win.

Actually it follows from their definition. Eclipse has positioned itself as an abstract platform for building anything with plug-ins, and IDEA is positioning itself as a “intelligent IDE for Java”. So it is.

For the sake of interest I will try to name some aspects in which the Eclipse is probably better than IDEA:

Eclipse looks better (thought, this is a matter of taste). All this fuss about SWT and native controls was worth it. Eclipse looks like a solid well thought-out application with pretty fonts and icons, while the IDEA at first glance looks like a stunt toy with a lame hack icons and awkward Swing interface.
Eclipse has a richer project structure support. In IDEA you have a project consisting of modules. In Eclipse you have a workspace consisting of projects which can be closed/opened, grouped and hidden. But do you actually need it?
It seems to be easier to write plugins for Eclipse.
IDEA uses more resources (memory) than Eclipse. This actually makes sense - because he knows so much.
And finally, Eclipse is free. However, IDEA Community Edition is just enough for me.

My final recommendation

If you need pretty icons, platform for creating desktop applications, IDE for C++, or you work on an old weak laptop, then Eclipse is problably better choice for you. But if you are a serious Java developer, and you need a fast and convenient tool that helps you focus on the problem instead of distracting, then the IDEA this is exactly what you need.

I hope one more holywar is over today.

Develop with pleasure!

Где спряталась логика?

2011-03-03T00:00:00+00:00

Вопрос

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

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

Так вот, кто скажет мне, что такое «логика»?

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

Ответ

Возможно, ответить на этот вопрос проще, если вместо слова «логика» использовать слово «знание». Логика — это любое знание о коде, или о том, как должен вести себя код. Можно ещё сформулировать так: «логика» — это всё, что вам хотелось хоть раз откомментировать.

Пример

Возьмём для примера класс Account, который я недавно откопал в своём проекте.

Было это так. В один прекрасный день у нас в офисе отрубился интернет на пару часов. Работать я фактически не мог — ну там, svn, jira, база знаний и прочее не были доступны. И решил я в качестве упражнения написать юнит-тест для какого-нибудь класса. И наткнулся на Account:

public class Account {
  // Негативное значение означает, что счёт предоплачен
  private BigDecimal amount;
  public BigDecimal getAmount() {
    return amount;
  }

  // И ещё два десятка геттеров и сеттеров
}

Казалось бы, что тут тестировать? Где IF’ы? Где тут логика? Казалось бы, нет её, и тестировать нечего. Я уже хотел было бросить этот класс и найти что-нибудь посложнее, как вдруг заметил комментарий около переменной amount:

Негативное значение означает, что счёт предоплачен

Это что ещё такое? Получается, что «amount» — это суммарная задолженность данного клиента, а если клиент внёс предоплату, то эта «задолженность» со знаком минус. Ну вот, это уже какое-то знание о коде. Попробуем-ка превратить этот комментарий в юнит-тест:

public class AccountTest {
  @Test
  public void negativeAmountMeansThatAccountIsPrepaid() {
    Account prepaidAccount = new Account(-123);
    assertTrue(prepaidAccount.isPrepaid());
  }
}

Раз мы проверяем случай негативного «amount», хорошо бы проверить и случай позитивного:

@Test
public void positiveAmountMeansThatAccountIsInDebt() {
  Account indebtAccount = new Account(456);
  assertFalse(indebtAccount.isPrepaid());
  assertTrue(indebtAccount.isInDebt());
}

Вот так ненароком у нас возникло два новых метода isPrepaid() и isInDebt(), реализация которых, конечно, очевидна:

public class Account {
  private BigDecimal amount;
  public boolean isInDebt() {
    return amount > 0;
  }
  public boolean isPrepaid() {
    return amount < 0;
  }
}

Вот видите, уже и IF’ы появились в коде! Следующая мысль, которая должна при этом прийти в голову: наверное, эти IF’ы уже были где-то раньше?

Пришлось немножко поискать, но это того стоило. Оказалось, что эти IF’ы действительно были в коде, причём не где-нибудь, а в JSP-файле, то есть в слое «view», в котором по определению никакой логики быть не должно:

<% Positive amount means that account is in debt %>
<c:if test="${account.amount > 0}">
  <span style="color: red;">Оплатите задолженность!</span>
</c:if>
<c:if test="${account.amount < 0}">
  <span style="color: green;">Предоплата</span>
</c:if>

Опаньки, как интересно! Вот и мой второй тест-кейс всплыл. Как замечательно. Теперь, поскольку у нас есть методы isInDebt() и isPrepaid(), мы можем убрать логику из JSP:

<c:if test="${account.inDebt}">
 <span style="color: red;">Оплатите задолженность!</span>
</c:if>
<c:if test="${account.prepaid}">
  <span style="color: green;">Предоплата</span>
</c:if>

Стало лучше? Я думаю, что стало. Это уже чуть больше похоже на инкапсуляцию — скрытие реализации от посторонних глаз. Только класс Amount знает, в каком случае клиент должен или не должен денег. Никто больше в целом мире не знает, как это происходит — клиент получает уже готовое решение с помощью методов isInDebt и isPrepaid. Теоретически значения «долг» и «предоплата» вообще могут храниться в разных колонках базы данных, или даже вообще в разных таблицах и вообще в разных базах. Теперь благодаря наличию двух методов эта логика спрятана (инкапсулирована) в классе Account.

Если вы всё ещё не верите, сравните объём кода.

ДО

<%-- Негативное значение означает, что счёт предоплачен %-->
<c:if test="${account.amount > 0}">
  <span style="color: red;">Оплатите задолженность!</span>
</c:if>

ПОСЛЕ

<c:if test="${account.inDebt}">
  <span style="color: red;">Оплатите задолженность!</span>
</c:if>

Можно пойти ещё дальше и вместо метода getAmount() сделать два разных метода getPrepaidAmount() и getDoubt(). Причём внутри них можно проверять, действительно ли у клиента есть долг или предоплата. То есть теперь невозможно будет, например, написать такой код:

<%-- Мало ли что у тебя предоплата, ты всё равно должен. %>
<c:if test="${account.amount != 0}">
  <font color="red">Оплатите задолженность!</font>
</c:if>

Да, это реальный код из того же проекта. Взгляните на него ещё раз, взгляните внимательно. “Мало ли что у тебя предоплата”. Блестяще! Вот где спраяталась аццкая логика! Пойди пойми теперь, что там было у людей на уме - у людей, которые не писали юнит-тест.

В идеале метод getAmount() теперь можно вообще стереть. Это и есть настоящая инкапсуляция: скрыть данные и код и дать доступ только через методы. Я думаю, если бы интернет не починили, я бы избавился и от остальных 20 геттеров-сеттеров.

Мораль

Вот видите, как юнит-тесты приводят к читаемому, объектно-ориентированному коду. А вы говорите: «В моём коде нет логики, там нечего тестировать…» Ещё как есть!

Логика есть, её не может не быть.

WTF is business logic?

2011-03-03T00:00:00+00:00

Question

I have heard many times the term “logic” or “business-logic” in discussions about software development. For instance:

(about unit-tests) it’s not necessary to achieve 100% code coverage, testing of logic is god enough.
(about web applications architecture) controller should not contain any business logic, it only should call other classes’s methods.
VIEW layer (e.g. JSP files) should not contain any business logic

Now tell me, what is “logic”?

Does it mean any IF in code? But, I don’t think that code without IFs ever existed. Or “business-logic” means any information that came from client? Actually I believe that all what we do is initiated by client, so all our code does contain information from client. That’s why I never could understand what the fuck is “business logic”.

Answer

Probably this question could be easier answered if you use term “knowledge” instead of “logic”. “Logic” is any knowledge about the code, or about how your code should behave. It may be also expressed like “logic is anything that you ever wanted to comment”.

Example

Let’s consider class Account for example.

Once upon a time Internet connection disappeared from our office for two hours. I actually could not work because SVN, jira, dabase etc. were not available. And I decided to exercise in writing unit-tests. So I found class Account:

public class Account {
  // Negative amount means that account is prepaid
  private BigDecimal amount;
  public BigDecimal getAmount() {
    return amount;
  }

  // And 20 getters/setters more
}

At the first glance, is there anything to test? Is there any IFs? Is there any logic? It seems that no. No logic, no IFs - nothing to test. I wanted to skip this class and find something more complicated, but eventually got sight of the comment near the amount field:

Negative amount means that account is prepaid

Wait, what is that?

It turns out that the amount is a total debt of the client, and if the client has made an advanced payment, then this “debt” is negative. Well, this is some knowledge about the code. Let’s try to convert this comment to unit-test:

public class AccountTest {
  @Test
  public void negativeAmountMeansThatAccountIsPrepaid() {
    Account prepaidAccount = new Account(-123);
    assertTrue(prepaidAccount.isPrepaid());
  }
}

Since we check for negative amount, it also would be reasonable to check for positive amount:

@Test
public void positiveAmountMeansThatAccountIsInDebt() {
  Account indebtAccount = new Account(456);
  assertFalse(indebtAccount.isPrepaid());
  assertTrue(indebtAccount.isInDebt());
}

We have eventually got two new methods isPrepaid and isInDebt, which implementation is of course straightforward for you:

public class Account {
  private BigDecimal amount;
  public boolean isInDebt() {
    return amount > 0;
  }
  public boolean isPrepaid() {
    return amount < 0;
  }
}

You see, we have got IF’s in our code! What’s next? You should have thought: probably, these IF’s already were somewhere in the code?

I had to search for such IF’s for a while, but it was worth it. These IFs were in JSP files, which is the “view” layer, which should not contain any business logic by definition:

<% Positive amount means that account is in debt %>
<c:if test="${account.amount > 0}">
  <span style="color: red;">Please pay your debt!</span>
</c:if>
<c:if test="${account.amount < 0}">
  <span style="color: green;">Advanced payment</span>
</c:if>

Wow, we have found the second test-case. Cool. Now, since we have methods isInDebt and isPrepaid, we can abandon logic in JSP:

<c:if test="${account.inDebt}">
 <span style="color: red;">Please pay tour debt!</span>
</c:if>
<c:if test="${account.prepaid}">
  <span style="color: green;">Advanced payment</span>
</c:if>

Is it better? I believe it is. This is encapsulation - hiding the implementation of logic from outer code. Class Amount is the only in the whole world who knows how to define, if client is in debt or has advanced payment. Other code doesn’t ever know how it happens - it can get resulting boolean throught methods isInDebt() and isPrepaid().

Theoretically “in debt” and “advanced payment” information could be stored in different columns, or event different tables, or even different databases. Nobody knows. Thanks to two methods, this logic is encapsulated in class Account.

If you still don’t believe, compare code size:

Before

<%-- Positive amount means that account is in debt %-->
<c:if test="${account.amount > 0}">
  <span style="color: red;">Please pay your debt!</span>
</c:if>

After

<c:if test="${account.inDebt}">
  <span style="color: red;">Please pay your debt!</span>
</c:if>

You can go further and create two different methods getPrepaidAmount() and getDebt() instead of method getAmount(). Additionally they can check, if the client has really debt or advanced payment. As a result, it’s impossible now to write a code like this one:

<%-- No matter if you have advanced payment, 
I still think that you are in debt! %>
<c:if test="${account.amount != 0}">
  <font color="red">Please pay your debt!</font>
</c:if>

Yeah, it’s a real code snippet. Look at this once more. “No matter if you have”. Pretty cool! That is WTF logic! It’s not possible to get to know what those people though - people who did not write unit-tests.

Ideally, method getAmount() should be removed. This would be the real encapsulation: hiding of data and code and making them available only throught API. I think I would remove all of 20 other getters/setters if internet connection wouldn’t get back to our office that day.

Moral

As You see, unit-tests lead you to readable, object-oriented code.

Are you still thinking that your code doesn’t contain logic? Are you still thinking that you code has nothing to test?

Of course it has!

Вдохновение для тестов

2011-02-10T00:00:00+00:00

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

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

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

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

Откуда брать вдохновение

Однажды я пришёл к удивительному открытию: это вдохновение — повсюду, оно окружает нас каждый день. Тут и придумывать ничего не надо. Его можно просто брать и использовать. Это открытие показалось мне настолько важным, что я спешу непременно поделиться им со всеми.

Итак, мой TOP-5 источников вдохновения для написания юнит-тестов.

5. Доклад начальнику

Каждое утро на собрании начальник спрашивает тебя:

– Что ты вчера делал?

– Багу исправлял.

Начальник так просто на слово не верит и продолжает докапываться:

-— Какую багу?

-— Ну, исправил метод validateReferenceNumber.

-— Конкретнее, что ты там исправил?

-— Ну, раньше он грохался, если дать ему на входе пустую строку, а теперь он не падает, а возвращает false.

Вот оно!

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

public class ReferenceNumberTest {
  @Test
  public void emptyStringIsNotValidReferenceNumber() {
    assertFalse(validateReferenceNumber(""));
  }
}

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

4. Объяснения с коллегами

К вам каждый день приходит какой-нибудь коллега и спрашивает:

-— Слушай, я тут твой код дебажу-дебажу, а всё никак не могу понять, как это работает?

Ты ему терпеливо объясняешь:

-— Ну как, ну смотри: сюда приходит Б, а отсюда выходит А.

-— Всё равно не понимаю, а почему А-то?

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

-— Ааа, вот теперь понятно.

И снова оно!

Вы, сами того не подозревая, только что сформулировали название тест-кейса. Мысленно послав +1 в карму коллеги, сели и написали:

public class NanoTechnologySecurityTest {
  @Test
  public void shouldReturnNextLetterForAllLettersExceptJa() {
    assertEquals("Б", encodeLetter("А"));
  }
}

3. Разговор с клиентом

В любой прекрасный день клиент может позвонить и сказать:

-— Помните, мы обсуждали, что все поля на форме должны валидироваться автоматически, как только поле теряет фокус? Так вот, я передумал. Я показывал бета-версию моей бабушке, и она сказала, что это не понятно, и вообще ajax sucks. Давайте поля будут валидироваться только тогда, когда клиент нажмёт кнопку «Submit».

И опять оно!

Клиент только что сформулировал за нас текст тест-кейса.

Мысленно послав -10 в карму клиента, мы сели и написали… UI тесты, конечно, чуток сложнее, чем обычные юнит-тесты, но это могло бы выглядеть как-то так:

public class TimotiFanClubRegistrationFormTest {
  @Test
  public void shouldValidateFieldsOnFormSubmission() {
    Form form = new Form();
    assertTrue(form.isValid());

    form.submit();
    assertFalse(form.isSubmitted());
    assertFalse(form.isValid());

    form.setName("Baba Njura");
    form.setEmail("Baba.Njura@yandex.ru");
    form.submit();
    assertTrue(form.isSubmitted());
  }
}

2. Баг

Каждый день вы заходите в Jira (а кому совсем повезло — в Pivotal Tracker) и обнаруживаете, что в вашей программе зловредные тестировщики нашли-таки багу. Если вам повезло с тестировщиком, то описание баги звучит примерно так:

«Если ввести три раза неправильный пароль, то учётная запись должна заблокироваться, а у меня не блокируется. Я уже раз пятнадцать ввёл.»

Мысленно сказав тестировщику спасибо (хватит с него и спасиба, его карму всё равно не спасёшь), садимся и пишем:

public class LoginPageTest {
  @Test
  public void shouldBlockAccountAfter3UnsuccessfulTries() {
    LoginPage page = new LoginPage();
    page.login("vasjok47", "Toiota");
    page.login("vasjok47", "Tojota");
    page.login("vasjok47", "tayota");
    assertTrue(AccountDAO.getAccount("vasjok47").isBlocked());
  }
}

Есть даже отдельный термин для этого: Bug driven development. Я сам этот подход не жалую, так как юнит-тесты (они же спецификация) всё-таки должны писаться ДО кода (основной принцип TDD), но как источник вдохновения баг-трекер вполне подходит.

1. Commit message (как это по-русски?)

Это мой любимый пункт, на нём я хотел бы остановиться подробнее.

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

Допустим, был у нас код, который валидировал email. В частности, он проверял, что в конце email должна быть точка и два символа. И даже есть для него юнит-тест, всё как у людей. И тут внезапно выясняется, что после точки может быть и больше букв, например, у некоторых клиентов email заканчивается на “.info”.

Сказано-сделано, код исправили, и даже в существующий юнит-тест добавили одну строчку:

public class EmailValidatorTest {
  @Test
  public void testValidateEmail() {
    assertTrue(validateEmail("timati@rambler.ru"));
    ...
    assertTrue(validateEmail("tina.turner@music.info")); // 4 letters now allowed!
  }
}

И теперь хотим это дело закоммитить в CVS (а кому повезло, те в SVN, а кто вообще счастливчик, те в GIT).

Для коммита надо написать пояснение (commit message), в котором обычно пишут, а что же в коде изменилось. И вот пишите вы:

svn commit -m "Теперяча мыло и на четыре буквы может заканчиваться."

И вот это самое настоящее оно-оно-оно!

Это то, что нам надо. Не нажимайте пока enter.

Остановились, выделили этот текст мышкой. Открыли класс юнит-теста. Написали Test, вставили скопированный текст и перевели на английский. Можно немножко уточнить или обобщить по вкусу.

public class EmailValidatorTest {
  @Test
  public void validEmailShouldEndWithDotFollowedBySeveralLetters() {
    assertTrue(validateEmail("timati@rambler.ru"));
    ...
    assertTrue(validateEmail("tina.turner@music.info"));
  }
}

Вот теперь можете смело закоммитить и мысленно послать +1 себе в карму. Сегодня мы смогли материализовать некоторые знания из воздуха во что-то более ощутимое. Теперь эти знания никуда не пропадут и будут автоматически проверяться при каждой сборке проекта.

Ну не здоровско ли, а?

Inspiration for tests

2011-02-10T00:00:00+00:00

not translated yet

Эволюция юнит-теста

2010-10-29T00:00:00+00:00

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

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

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

Попытка номер №1: типичный тест

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

public class ReferenceNumberTest {  
  @Test  
  public void testValidate() {  
    assertFalse( ReferenceNumber.validate("1234567890123") );  
    assertFalse( ReferenceNumber.validate("1234567") );  
    assertTrue( ReferenceNumber.validate("12345678") );  
  }  
}

Мы называем это типичным юнит-тестом. Он тестирует код, но и только. Больше никаких преимуществ у него нет. Он не объясняет, почему именно такие значения. Почему “12345678” - корректное значение? Почему “1234567” - некорректное? Кто сказал?
Именно после такого кода скептики делают вывод, что от юнит-тестов нет особой пользы.

Попытка номер №2: хороший тест

В какой-то момент пришёл разработчик и решил применить к этому коду некоторые “best practices” из TDD: разбить тест-метод на несколько маленьких, так чтобы каждый из них тестировал только одну вещь, и дать им соответствующие имена.

Вот что у него получилось:

public class ReferenceNumberTest {  
  @Test  
  public void testTooLong() {  
    String len13 = "1234567891111";  
    assertEquals(len13.length(), 13);  
    assertEquals(ReferenceNumber.validate(len13), false);  
  }  
  
  @Test  
  public void testTooShort() {  
    String len7 = "1234567";  
    assertEquals(len7.length(), 7);  
    assertEquals(ReferenceNumber.validate(len7), false);  
  }  
  
  @Test  
  public void testOk() {  
    String len8 = "12345678";  
    assertEquals(len8.length(), 8);  
    assertEquals(ReferenceNumber.validate(len8), true);  
  
    String len12 = "123456789111";  
    assertEquals(len12.length(), 12);  
    assertEquals(ReferenceNumber.validate(len12), true);  
  }  
}

Мы называем это хорошим юнит-тестом. Он гораздо легче читается: по названиям переменных легко догадаться, что 13 символов — это слишком много, 7 — слишком мало, а 8 символов — это нормально.

Попытка номер №3: спецификация

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

Разработчик продолжает процесс разбивки и переименования:

public class ReferenceNumberTest {  
  @Test  
  public void nullIsNotValidReferenceNumber() {  
    assertFalse(ReferenceNumber.validate(null));  
  }  
  
  @Test  
  public void referenceNumberShouldBeShorterThan13() {  
    assertFalse(ReferenceNumber.validate("1234567890123"));  
  }  
  
  @Test  
  public void referenceNumberShouldBeLongerThan7() {  
    assertFalse(ReferenceNumber.validate("1234567"));  
  }  
  
  @Test  
  public void referenceNumberShouldContainOnlyNumbers() {  
    assertFalse(ReferenceNumber.validate("1234567ab"));  
    assertFalse(ReferenceNumber.validate("abcdefghi"));  
    assertFalse(ReferenceNumber.validate("---------"));  
    assertFalse(ReferenceNumber.validate("         "));  
  }  
  
  @Test  
  public void validReferenceNumberExamples() {  
    assertTrue(ReferenceNumber.validate("12345678"));  
    assertTrue(ReferenceNumber.validate("123456789"));  
    assertTrue(ReferenceNumber.validate("1234567890"));  
    assertTrue(ReferenceNumber.validate("12345678901"));  
    assertTrue(ReferenceNumber.validate("123456789012"));  
  }  
}

Мы называем это спецификацией в стиле BDD.

Названия методов говорят почти на человеческом языке о том, как должен работать код. Мысленно вставив перед заглавными буквами пробелы, мы получаем спецификацию кода на английском языке. Чтобы понять, как работает класс, мы не должны залезать в код — достаточно прочитать называния. А если в ходе изменения кода в него внесли ошибку, и юнит-тест сломался, мы по названию сломавшегося тест-метода наверняка сможем определить, что за ошибка допущена в коде.

Между прочим, с этим примером произошла интересная история. Однажды я собирался показать этот пример эволюции юнит-теста на семинаре devclub.eu по BDD в Таллине. И вот, за день до семинара я обнаружил, что я забыл скопировать исходный код самого класса ReferenceNumber, который мы тут всю дорогу тестируем. Что делать? Паника! До семинара остался один день! Мне нужно было срочно самому написать его заново.

А теперь посмотрите на эти три тест-класса и подумайте, какой из них помог мне восстановить логику класса ReferenceNumber.

И наконец, BDD

Можно сказать, третья версия отличается от предыдущих тем, что она описывает поведение класса. Это достигается за счёт использования таких слов как «should» и «contain»: «мой класс должен вести себя так-то и так-то», «мой метод должен делать то-то и то-то».

Так вот, идея BDD как раз и заключается в том, чтобы вместо слов «test» и «assert» использовать слова «spec» и «should». Да-да, разница всего лишь в словах, но именно это, по замыслу авторов BDD, и делает спецификации удобочитаемыми, а написание тестов спецификаций до кода — естественным для человеческого мозга.

Убедиться в этом вы можете, взглянув на тот же пример, переведённый с языка JUnit на язык Easyb:

description "ReferenceNumber"

it "should not be null", {
  ReferenceNumber.validate(null).shouldBe false
}

it "should be shorter than 13", {
  ReferenceNumber.validate("1234567890123").shouldBe false
}

it "should be longer than 7", {
  ReferenceNumber.validate("1234567").shouldBe false
}

it "should contain only numbers", {
  ReferenceNumber.validate("1234567ab").shouldBe false
  ReferenceNumber.validate("abcdefghi").shouldBe false
  ReferenceNumber.validate("---------").shouldBe false
  ReferenceNumber.validate("         ").shouldBe false
}

it "valid reference number examples", {
  ReferenceNumber.validate("12345678").shouldBe true
  ReferenceNumber.validate("123456789").shouldBe true
  ReferenceNumber.validate("1234567890").shouldBe true
  ReferenceNumber.validate("12345678901").shouldBe true
  ReferenceNumber.validate("123456789012").shouldBe true
}

Отчёт о запуске этих тестов спецификаций фактически может служить документацией:

Кроме it и should, в BDD есть и другие важные слова, такие как given, when и then, а также before и after, ну и вдобавок ensure, narrative и «should behave as». Также BDD подходит не только для юнит-тестов, но и для функциональных/интеграционных тестов, но это уже выходит за рамки данной статьи. Сейчас нас интересует уровень юнит-тестов. Цель данной статьи — показать, что их можно писать по-разному.

Осталось добавить, что библиотеки для написания BDD спецификаций есть и для других языков: Java (JDave, JBehave), Ruby (RSpec, RBehave, Cucumber), Groovy (Easyb), Scala (Scala-test), PHP (Behat), CPP (CppSpec), .Net (SpecFlow, Shouldly), Python (Lettuce, Cucumber).

А если по независящим от вас причинам вы не можете пересесть с JUnit на что-то другое — тоже ничего, только помните о третьем примере. Кстати, в этом случае вам пригодится библиотека Harmcrest.

Как завещал Козьма Прутков: товарищ, BDDи!

Unit-test evolution

2010-10-29T00:00:00+00:00

TDD is not absolute goodness. Tests can be different.

Let’s consider how bad can be unit-test and how can it evolve.

Typical test

This is an example of unit-test evolution which I presented on recent devclub.eu workshop. Let’s consider 3 revisions of the same unit-test class. This is the first revision of this class:

public class ReferenceNumberTest {
  @Test
  public void testValidate() {
    assertFalse( ReferenceNumber.validate("1234567890123") );
    assertFalse( ReferenceNumber.validate("1234567") );
    assertTrue( ReferenceNumber.validate("12345678") );
  }
}

We call it a typical unit-test. It’s not ideal: it fixes behaviour, but does not explain it. Why is “12345678” valid? Why “1234567” is not? One monolithic test verifies multiple requirements. If one check fails - the whole test fails.

Good test

At some moment, some developer decides to apply some TDD best practices and split this test-method into 3 with some meaningful names. This is what he got:

public class ReferenceNumberTest {
  @Test
  public void testTooLong() {
    String len13 = "1234567891111";
    assertEquals(len13.length(), 13);
    assertEquals(ReferenceNumber.validate(len13), false);
  }


  @Test
  public void testTooShort() {
    String len7 = "1234567";
    assertEquals(len7.length(), 7);
    assertEquals(ReferenceNumber.validate(len7), false);
  }


  @Test
  public void testOk() {
    String len8 = "12345678";
    assertEquals(len8.length(), 8);
    assertEquals(ReferenceNumber.validate(len8), true);


    String len12 = "123456789111";
    assertEquals(len12.length(), 12);
    assertEquals(ReferenceNumber.validate(len12), true);
  }
}

We call it good unit-test.

Executable specification

After some time, some developer decides that even this good unit-test is not human-readable and does not provide enough information about how class ReferenceNumber should work. He continued splitting and renaming. This is what he got at the end:

public class ReferenceNumberTest {
  @Test
  public void nullIsNotValidReferenceNumber() {
    assertFalse(ReferenceNumber.validate(null));
  }


  @Test
  public void referenceNumberShouldBeShorterThan13() {
    assertFalse(ReferenceNumber.validate("1234567890123"));
  }


  @Test
  public void referenceNumberShouldBeLongerThan7() {
    assertFalse(ReferenceNumber.validate("1234567"));
  }


  @Test
  public void referenceNumberShouldContainOnlyNumbers() {
    assertFalse(ReferenceNumber.validate("1234567ab"));
    assertFalse(ReferenceNumber.validate("abcdefghi"));
    assertFalse(ReferenceNumber.validate("---------"));
    assertFalse(ReferenceNumber.validate(" "));
  }


  @Test
  public void validReferenceNumberExamples() {
    assertTrue(ReferenceNumber.validate("12345678"));
    assertTrue(ReferenceNumber.validate("123456789"));
    assertTrue(ReferenceNumber.validate("1234567890"));
    assertTrue(ReferenceNumber.validate("12345678901"));
    assertTrue(ReferenceNumber.validate("123456789012"));
  }
}

We call it BDD style specification. It explains requirements. It explains how code should behave and why. It explains customer’s expectations.

And finally, the most interesting part. I had to show this example on devclub.eu session. But.. at some moment I discovered that I haven’t copied the original source code of the class ReferenceNumber being tested.

Panic!

One day left!

I had to urgently re-create it from scratch! Now look at these 3 test-classes, and imagine, which of them helped me to create class ReferenceNumber.

And finally, BDD

You could observe that the third test is different because it describes behaviour of class. It’s accomplished by using words «should» and «contain»: «my class should behave like that», «my method should do this».

So, BDD idea is to use words “spec” and “should” instead of «test» and «assert». Yes, the difference is only a few words, but it makes tests (sorry, specifications) more readable, and writing tests before code more natural for human brains.

You can make sure in it if you look at the same example translated from JUnit to Easyb:

description "ReferenceNumber"

it "should not be null", {
  ReferenceNumber.validate(null).shouldBe false
}

it "should be shorter than 13", {
  ReferenceNumber.validate("1234567890123").shouldBe false
}

it "should be longer than 7", {
  ReferenceNumber.validate("1234567").shouldBe false
}

it "should contain only numbers", {
  ReferenceNumber.validate("1234567ab").shouldBe false
  ReferenceNumber.validate("abcdefghi").shouldBe false
  ReferenceNumber.validate("---------").shouldBe false
  ReferenceNumber.validate("         ").shouldBe false
}

it "valid reference number examples", {
  ReferenceNumber.validate("12345678").shouldBe true
  ReferenceNumber.validate("123456789").shouldBe true
  ReferenceNumber.validate("1234567890").shouldBe true
  ReferenceNumber.validate("12345678901").shouldBe true
  ReferenceNumber.validate("123456789012").shouldBe true
}

Test report can server as a documentation:

In addition to it and should, BDD also suggests using other keywords, such as given, when and then, also before and after, and ensure, narrative and «should behave as».

BDD suits not only for unit-tests, but also for functional/integrations tests. You can see that tests can be different.

I must remain that there is also a plenty of BDD frameworks for different languages: Java (JDave, JBehave), Ruby (RSpec, RBehave, Cucumber), Groovy (Easyb), Scala (Scala-test), PHP (Behat), CPP (CppSpec), .Net (SpecFlow, Shouldly), Python (Lettuce, Cucumber).

But if you still need to use JUnit — it’s also ok, just remember the third example. And try using Harmcrest with JUnit.

Do you feel BDDevolution?

Зачем дьявол придумал javadoc

2010-05-02T00:00:00+00:00

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

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

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

Например

Возьмём пример из жизни. Это реальный код, написанный вполне старательным программистом, который не поленился и написал комментарий к своему методу. Довольный собой, но пошёл налить себе чашечку кофе из аппарата, а мы давайте-ка пока посмотрим, что же тут у нас есть.

public class AddressUtil {
   /**
    * Format string as address, expected input
    * format:"EE ; ;Tallinn;Narva mnt;120B;831;10127"
    *
    * @param flatAddress
    * @return Formatted address
    */
   public static String toString(String flatAddress) {......}
}

Отлично! У нас есть корректно оформленный комментарий в формате javadoc, из которого специальная программа сможет сгенерировать HTML-документацию. По нему легко можно понять, что (теоретически) делает этот метод.

Где же спрятался дьявол?

Но где же те мелочи, в которых спрятался дьявол? А вот они:

Очень скоро эта документация устареет, потому что придёт другой девелопер и поменяет код, но забудет поменять документацию. Это может быть даже тот же самый девелопер, потому что пока он стоял в очереди за кофе, ему пришло в голову, что он забыл обработать один редкий случай. Вернувшись, он добавит нужный IF в код, но забудет о том, что у него уже есть javadoc, который необходимо поддерживать.
В документации не описаны масса случаев: как поведёт себя метод, если на входе придёт null или пустая строка? Что, если в адресе есть номер дома, но нет номера квартиры (то есть буржуй занял дом целиком)? Что там за пустой параметр между EE и Tallinn?
В документации нет ни слова о том, что этот метод возвращает.
В документации есть целых три лишних строчки: “*”, “@param flatAddress” и “@return Formatted address”. Только подумайте: они занимают большую часть документации, и они абсолютно бесполезны!

Волшебство

А теперь давайте поиграем в волшебников и превратим несколько цветных кусочков в гирлянду. Сделаем несколько магических пассов. Сим-салябим, Ахалай-махалай, Ляськи-масяськи….

Пасс номер 1: Основной текст из комментария Format string as address превращаем в название метода: toString -> formatAddress.
Пасс номер 2: Описание параметра expected input, expected: ... из комментария переносим в юнит-тест.
Пасс номер 3: (мой любимый) Весь остальной комментарий стираем нахрен. Не жалейте его, он зря появился на свет! Это кодская спарта!

Что у нас получилось в итоге?

public class AddressUtil {
  public static String formatAddress(String flatAddress) {......}
}

public class AddressUtilTest {
  @Test public void testFormatAddress() {
    assertEquals("Narva mnt 120B-831  10127 Tallinn", 
      AddressUtil.formatAddress("EE ; ;Tallinn;Narva mnt;120B;831;10127"));
  }
}

Чем же новый вариант лучше старого?

Он тупо короче: было 8 строк, стало 4.
Этот тест никогда не устареет, т.к. он будет запускаться автоматически каждый раз при сборке проекта, и если программист поменяет код, а о методе забудет, это сразу всплывёт.
Можно описать все редкие случаи: пустые строки, отсутствующие параметры, недопустимые значения и т.д.

Одним словом,

ХОРОШЕЕ НАЗВАНИЕ + ТЕСТЫ = ДОКУМЕНТАЦИЯπ

а точнее, “запускаемая документация” (executable documentation), то есть документация, которую можно не просто читать, но ещё и “запускать”, автоматически проверяя, что она всё ещё адекватна.

Говорят, у Конфуция над кроватью висел плакат:

Convert comments to executable documentation

Послесловие

Боюсь только, что наш доблестный программист, вернувшись с кухни, фокуса не поймёт, ведь он не видел наших волшебных движений. Ему снесёт башню от одного только факта, что его комментарии КТО-ТО НАГЛО ПОТЁР, и он постарается нас найти и уничтожить за такую подрывную деятельность.

А его кофе тем временем остынет. Ну что ж, и то неплохо: ведь кофе, говорят, вреден. Значит, одно хорошее дело мы всё-таки сегодня сделали.

Why the devil invented javadoc?

2010-05-02T00:00:00+00:00

It is believed that a good program should be well documented.

SUN company even creared a special format javadoc - “a standard for documenting classes Java”. In fact, it was quite a common case in my experience, when a code did not pass Code Review just because some of its methods lacked comments.

Today I’ll tell you why the comments are evil.

Start from example

Consider the real example from live code. This is a real code written quite diligent programmer who was not lazy and wrote a commentary on his method. Pleased with himself, he went to pour himself a cup of coffee from the machine. While he is going to the office kitchen, let’s take a look at what we have here.

public class AddressUtil {
   /**
    * Format string as address, expected input
    * format:"EE ; ;Tallinn;Narva mnt;120B;831;10127"
    *
    * @param flatAddress
    * @return Formatted address
    */
   public static String toString(String flatAddress) {......}
}

Excellent! We have a correctly designed a format javadoc, from which a special program can generate HTML-documentation. As it is easy to see that (theoretically) makes this method.

Where is the hidden devil?

But where are those little things that hid the devil? And here they are:

Very soon this documentation becomes outdated, because some other developer will come and change the code, but forget to change the documentation. It may even be the same developer, because while he was standing in line for coffee, it occurred to him that he forgot to process one rare case. When he comes back, he adds the desired IF into the code, but forgets that he already has javadoc, which needs to be maintained.
This documentation does not describe the mass of cases: how the method behaves, if the input comes null or empty string? What if address contains house number, but misses apartment number (ie bourgeois took home a whole)? What’s that empty parameter between the EE and Tallinn?
Documentation doesn’t describe what this method returns.
There are three extra lines in the documentation: “*, “@ param flatAddress” and “@ return Formatted address”. Just think: they occupy a large part of the documentation, and they are absolutely useless!

It can be summarized in two words:

Comments lies!

That’s all. You cannot do anything with this, except the cases when you have a special position for people how review all the documentation periodically. Damn, do you really want to do that?

The magic

Now let’s do a focus-pocus and create The Magic. We make a few magical passes. Sim salyabim, Ahalan-mahalay, Lyaska-masyaski ….

Pass # 1: Transform the main comment Format string as address to a method name: toString -> formatAddress.
Pass #2: Transform parameter description expected input, expected: ... from comment to a unit-test.
Pass #3 (my favorite): (мой любимый) All other comment text - wipe fuckin! Do not spare him, it was born in vain! This is coding sparta!

What we have in the end?

public class AddressUtil {
  public static String formatAddress(String flatAddress) {......}
}

public class AddressUtilTest {
  @Test public void testFormatAddress() {
    assertEquals("Narva mnt 120B-831  10127 Tallinn", 
      AddressUtil.formatAddress("EE ; ;Tallinn;Narva mnt;120B;831;10127"));
  }
}

What the new version better than the old?

It’s just shorter: there are now 4 rows compared to former 8.
This test will never becomes obsolete, because it will run automatically every time you build the project, and if the programmer change the code, and forget about the method, it immediately pops up.
You can describe all the rare cases: the empty string, missing keys, invalid values, etc.

In short,

GOOD TITLE + TESTS = DOCUMENTATION

rather, executable documentation, or documentation that can not only read but also “run”, automatically checking that it is still adequate.

It is said that Confucius was a poster over the bed:

Convert comments to executable documentation

Afterword

I’m just afraid that our brave programmer, returning from the kitchen, will not understand the focus, because he had not seen our magical movements. He will get mad only because SOMEONE Nagle has deleted his comments, and he will try to find us and kill for such subversive activities.

… And his coffee gets cool in the meantime. Well, no so bad: after all, coffee, they say, is harmful. So, we did today did one good thing.

Andrei Solntsev

Mockito научился мокать статические методы!

Шаг 1: зависимость

Шаг 2: что мокаем

Шаг 3: Мокаем статический метод

Mockito can mock static methods!

Step 1: dependency

Step 2: what are we going to mock

Step 3: Mock the static method

Миграция на Mockito 2.1

Тотальный облом

Что надо сделать

Первым делом ты заменишь импорты

Затем ты обновишь API функции doAnswer

Дальше ты обновишь API isMock

На какие грабли ты наступишь

1) Матчер any() больше не срабатывает на null

2) Матчер anyInt() больше не срабатывает на параметр типа long

3) Ты обнаружишь у себя плохие тесты

4) Ты обнаружишь у себя много неряшливых тестов

5) Ты обнаружишь мистические красные тесты

6) Ты нарвёшься на то, что anyList() и anyCollection() - теперь разные вещи

И будешь доволен как слон

Migration to Mockito 2.1

Epic fail

What you need to do

First, you will need to replace import

Second, you will update API of doAnswer

Third, you update API of isMock

What problems you will experience

1) Matcher any() does not match null anymore

2) Matcher anyInt() does not match long anymore

3) You will discover bad tests

4) You will discover a lot of sloppy tests

5) You will discover mystical red tests

6) You will find out that anyList() and anyCollection() are now different things

And you will be happy

Spring boobs

И понеслось!

И что теперь

И вот…

Короче

Spring boobs

And it began!

And what now?

And then…

Finally

О Legacy-коде

About Legacy code

Почему разработчики должны быть хорошими тестировщиками

1. “Родительские чувства” к коду

2. Акцентирование на позитивных моментах

3. Работа на основе принципа упрощения сложных вещей

4. Неспособность видеть мелкие детали на большой картине

5. Недостаток опыта работы с типичными багами и программными ошибками

Настоящие пэдж-объекты

Классический пэдж обжект

В чём же подвох?

Что же делать?

Контрольный в мозг

Что на самом деле нельзя хардкодить

Хардкод

Классический хардкод

Давайте разбираться в причинах

Почему эти причины не катят?

Ладно, ладно

А что же - самый страшный хардкод?

Что же делать?

Упростим

Юнит-тесты

Пэдж обжекты

Как Java8 может помочь в написании юнит-тестов

Проблема

Как решается сейчас

Вариант 1: засилье конструкторов

Вариант 2: засилье null

Вариант 3: засилье вспомогательных методов

Вариант 4: засилье билдеров

И что же даст Java 8?

How Java8 can help in writing unit-tests

1) Матчер `any()` больше не срабатывает на `null`

1) Matcher `any()` does not match `null` anymore

Вариант 2: засилье `null`

Option 2: lot of `null`s