👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

слабенько, давай бдд через jbehave. А заодно на arquillian, потому как моки — давно прошлый век.
Кстати, кто-то там ниже писал про предикаты из гуавы и хамкреста — так вот, я пытался их подружить — получилось коряво крайне, оставил чистый хамкрест. Потому что они предназначены принципиально для разных задач. И кстати в 4 джейюните идет только базовые матчеры хамкреста, эдвансед нету.

А заодно на arquillian
We believe that integration and functional testing should be no more complex or daunting than unit testing. We created Arquillian to make that vision a reality.
Я рассказываю про модульные тесты, а вы приводите инструмент для функционального и интеграционного тестирования.

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

Так это ортогональные проверки.
Алгоритм поиска медианы в списке — проверяем модульными тестами, корректность добавления товара в корзину покупок — функциональными.
Он независимо сосуществуют в проекте.

а есть ли где-то на рынке труда Харькова компании, работающие с _алгоритмами_, а не формочками? Или, например, баланс в tower-defense игре проверять какими тестами?

Вы сейчас смеетесь или действительно не понимаете что проверяется модульными тестами?
Любая логика, даже под формочками, любой нетривиальный контроллер, содержащий вложенные for/if/while/switch, желательно покрыть модульными тестами.

Любая логика, даже под формочками, любой нетривиальный контроллер, содержащий вложенные for/if/while/switch, желательно покрыть модульными тестами.
Вот именно с этим я частично не согласен и считаю, что модульные тесты в обычном веб-приложении — пустая трата времени, так как они не дают никакого бизнес-значения, в отличии от интеграционного. Более того, отдельный бин может быть покрыт тестами на 100 процентов со всеми ветками и прочим, но это не говорит ровным счетом ничего о том, выполняет ли он поставленную задачу. На мой взгляд, при достаточно полных интеграционных тестах модульные не нужны. Ну, это лишь мое имхо. Что, впрочем, подтверждается, например, косвенно и тут habrahabr.ru/post/182458
Теперь я заказчик и понимаю, что мне нафиг не нужен идеальный код, депенденси инджекшены и два синьора по цене одного. Главное, чтобы работало и было сделано в срок.
Главное, чтобы работало и было сделано в срок.
Да, но заказчик не понимает как получается «что бы просто работало».
Я только ЗА интеграционное/функциональное тестирование, но я против полного отсутствия модульных тестов. Но, впрочем, это уже специфика каждого отдельного проекта.
И кстати в 4 джейюните идет только базовые матчеры хамкреста, эдвансед нету.
А кто мешает взять самому оригинальные матчеры?

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

давай бдд через jbehave.
Честно говоря, не совсем понимаю чем БДД отличается от ТДД кроме желания автора фреймворка придумать новый термин и войти в историю.
Честно говоря, не совсем понимаю чем БДД отличается от ТДД
Если коротко и неправильно, то:
БДД — это про разработку функциональности.
ТДД — про написание кода.
На уровне туллинга, отличия те же что и у хамкреста от джЮнита: более человекочитаемые тесты/спеки. Попытка структурировать написание тестовых сценариев.

БДД позволяет формализировать юзер-стори и приемочные тесты в простом текстовом виде, одинаково понятном как для машин, так и для людей. Этим достигается реализация хотелок заказчика в один шаг. Т.е. User story -> behavior тесты -> код, который по определению удовлетворяет требованиям заказчика.

Т.е. БДД — это про функциональные тесты, а ТДД — про модульные?

Или вот такой пример:

import org.junit.Test;
import java.util.List;
import static java.util.Arrays.asList;
import static org.hamcrest.Matchers.anyOf;
import static org.hamcrest.Matchers.hasItem;
import static org.junit.Assert.assertThat;

public class HamcrestExample {
@Test
public void test2() {
List<string> list = asList("A", "B", "C");
assertThat(list, anyOf(hasItem("A"), hasItem("X")));
}
}

А чем это лучше

assertTrue(list.contains("A") || list.contains("B"));
Зачем прикручивать еще одну либу с мутным DSL-ем?
Зачем прикручивать еще одну либу с мутным DSL-ем?
В 4+ (см последние версии) jUnit-ах она идет из коробки.
assertTrue(list.contains("A") || list.contains("B"));
assertThat(list.size(), equalTo(10));
assertEquals(list.size(), 10); // TestNG
assertEquals(10, list.size()); // jUnit
Преимущества будут видны когда предикаты будут сложные и/или когда надо их шарить между разными тестами. Можно и без этого. Дело вкуса, конечно.
Из явных недостатков, конфликт при статическом импорте с Mockito.
Преимущества будут видны когда предикаты будут сложные и/или когда надо их шарить между разными тестами. Можно и без этого. Дело вкуса, конечно.
А чем оно лучше аналогичных предикатов от Guava & Jakarta commons которые в придачу еще интегрированы в соответствующие collections libraries?
А чем оно лучше аналогичных предикатов от Guava & Jakarta commons
Напишите на них ассерт:
assertThat(list.size(), equalTo(10));
assertEquals(list.size(), 10); // TestNG
assertEquals(10, list.size()); // jUnit

Предикат на гуаве будет выглядеть как equalTo(10) это раз.
Твой пример намного логичнее сделать на чистой джаве, как это и сделано в двух примерах из трех в твоем коде, это два.
У тебя есть сомнения что библиотека предикатов в guava & jakarta мощнее обсуждаемого вялосипеда?
Ну и вообще именно на джаве я бы сложную логику валидации запихнул бы в отдельный класс/метод а не писал бы предикаты на птичьем ограниченном DSL-e.

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

А как именно она пострадает? Можно пример с библиотекой предикатов и без?

actual.ShouldBeEquivalentTo(expected, options =>
options.Excluding(o => o.Customer.Name));
ну там еще какие-то проперти выкидываем при сравнении.
а если вы напишете какой-то свой кастомный ассерт или же просто метод для сравнения и ваш ассерт спустя какое-то время провалится — вам придется идти в свой метод сравнения или кастом ассершн, а так всё на виду прямо в юнит тесте.

по хорошему вам и тот метод придется покрывать юнит тестами

Твой пример я так понимаю иррелевантен джаве и к топику не относится?

не думаю, что язык тут играет какую-то роль.

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

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

Нифига не одни, так как вполне можешь упереться что в библиотеке предикатов нету каких то элементарных вещей тима if then else, или цикла по коллекции, и придется разбираться во внутренностях либы и писать какие то предикаты руками, что уже тоже самое что выбосить сложные ассерты в другой класс.

ну это уже другой вопрос. ведь сложные ассерты или ветвление в одном юнит тесте — это плохо. лучше разнести на несколько юнит тестов

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

тоже верно. если библиотека с ассертами не дает большей наглядности по сравнению со стандартными ассертами — то такая библиотека не нужна и она от лукавого

Предикат на гуаве будет выглядеть как equalTo(10) это раз.
А ассерт? Напишите ассерт.
Мой вариант:
assertTrue(equalTo10(list.size()));
Менее читабельно чем:
assertThat(list.size(), equalTo(10));
Банально из-за структуры предложения.
как это и сделано в двух примерах из трех в твоем коде, это два.
А вы знаете почему эти примеры разные? Подсказка: где там ожидаемое значение? А если вместо 10 будет, например, размер другого листа?
У тебя есть сомнения что библиотека предикатов в guava & jakarta мощнее обсуждаемого вялосипеда?
1) А чем ваши велосипеди (гуава и коммонсы) мощнее ванильной джавы?
2) Тут дело не в мощности. Хамкрест просто больше заточен под тесты. Почитайте доку.
Ну и вообще именно на джаве я бы сложную логику валидации запихнул бы в отдельный класс/метод а не писал бы предикаты на птичьем ограниченном DSL-e.
Вместе с ассертами будет плохо, пропадет их наглядность. А без ассертов будет хуже читаемость, чем у __псевдо__ДСЛ хамкреста. Фактически хамкрест предоставляет точку интеграции и общий интерфейс для вашего вынесения в метод/класс, а накладных расходов минимум.
А ассерт? Напишите ассерт.
Мой вариант:
assertTrue(equalTo10(list.size()));
Менее читабельно чем:
assertThat(list.size(), equalTo(10));
Банально из-за структуры предложения.
да, есть небольшой синтаксический сахар, который как я уже писал нивелируется тем что я бы этот тест написал бы на джава.
А вы знаете почему эти примеры разные? Подсказка: где там ожидаемое значение?
Спасибо Кеп, и как это относится к топику?

А если вместо 10 будет, например, размер другого листа?
Ты надеюсь сам осилишь написать тривиальную валидацию для этого случая? В чем твоя мысль?
1) А чем ваши велосипеди (гуава и коммонсы) мощнее ванильной джавы?
Тем что позволяют строить предикаты и имеют кучу интегрированной функциональности, типа хелперов, коллекций, асинхронных futures.
2) Тут дело не в мощности. Хамкрест просто больше заточен под тесты. Почитайте доку.
Так я и спрашиваю, в чем заточенность?
Вместе с ассертами будет плохо, пропадет их наглядность. А без ассертов будет хуже читаемость, чем у __псевдо__ДСЛ хамкреста. Фактически хамкрест предоставляет точку интеграции и общий интерфейс для вашего вынесения в метод/класс, а накладных расходов минимум.
Это все эпитеты. Почему пропадает наглядность? Почему читабельность хуже? Почему хамкрест для вынесения логики лучше чем гуава?
Спасибо Кеп, и как это относится к топику?
Незашо, Кэп. Как кэп кэпу: Читабельность :)
В чем твоя мысль?
Кэп говорит: понятность и простота. В случае с хамкрестом понятнее где актуально, а где ожидаемое ... стоп, их нет есть просто утверждения — и это лучше для понимания, поскольку это ближе к нативному языку.
Так я и спрашиваю, в чем заточенность?
Ну откройте доку челе.
Почему хамкрест для вынесения логики лучше чем гуава?
Напишите на них ассерт:
assertThat(list.size(), equalTo(10));
И поймете :)
Незашо, Кэп. Как кэп кэпу: Читабельность :)
Может не кеп кепу, а кеп телепату? Где, какая читабельность?
Кэп говорит: понятность и простота. В случае с хамкрестом понятнее где актуально, а где ожидаемое ... стоп, их нет есть просто утверждения — и это лучше для понимания, поскольку это ближе к нативному языку.
Так я и спрашиваю, в чем заточенность?
Ну откройте доку челе.
Почему хамкрест для вынесения логики лучше чем гуава?
Напишите на них ассерт:
assertThat(list.size(), equalTo(10));
И поймете :)
Раз аргументы с твоей стороны закончились, попробую обьяснить на твоем языке эпитетов: твой DSL поощряет писать нечитабельный труднодебажимый недофункциональный код, заставляя при этом изобретать костыли, так как в нем отсутствует куча утилит присутствующих в Гуава. Если не понятно — читай доки и попробуй написать сложные примеры на том и другом.

Ну, например, в случае поломки

@Test
public void test2() {
List<string> list = asList("A", "B", "C");
assertThat(list, anyOf(hasItem("AAA"), hasItem("X")));
}
видно красивое многоэтажное ругательство:
java.lang.AssertionError:
Expected: (a collection containing “AAA” or a collection containing “X”)
but: was <[A, B, C]>

Все равно человек фиксящий тест будет смотреть код, и увидит тоже самое в джава коде.

Также идея в том, что можно создавать свои Matcher для своих типов.
Скажем для Product можно иметь ProductMathcer.isCheapProduct? ProductMathcer.isProductForWoman, ...

А скажем в гуава нельзя сделать такие же предикаты?

А почему ты не приводишь примеры? Доставая свой пример, не дрейфь, и давай мериться:)

Твои примеры матчеров тоже более чем абстрактны, не понятно пример чего именно мне нужно написать?

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

Да, все.
Если интересно — брошу больше сюда.

ну блин :) это был сарказм :)
нельзя было тест как-то повыразительнее назвать?
это ведь очень принципиально

Ну так до семинара еще 4 дня.

Hamcrest, как считают его авторы, можно назвать библиотекой для построения декларативных предикатов.
Скажем такой пример:

import org.junit.Test;
import static java.lang.Math.sin;
import static org.hamcrest.Matchers.closeTo;
import static org.hamcrest.Matchers.is;
import static org.junit.Assert.assertThat;

public class HamcrestExample {
private static final double ERROR = 0.000_001;
@Test
public void test0() {
assertThat(sin(0.0), is(closeTo(0.0, ERROR)));
}
}

Подписаться на комментарии