и в конце даже примерычи на скале есть

ничоси

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

ну grate еще придумали

http://r6research.livejournal.com/28050.html

это всё в общем то из серии datatype-generic, где мультиплейты и шейплессы

только в качестве базы берется не функтор а профунктор

чтобы можно было туда и сюда

Вопрос по тестированию. Кто как тестирует бизнес-логику, которая взаимодействует с внешними сервисами, например делает запросы к REST-API или к БД? Кто чем мокает (mock) такие сервисы? ScalaMock ?

Mockito

Mockito

Он же джавайский? Или есть scala обертка?

А в чем проблема то?

Он прекрасно мокает трейты

ServiceT, ServiceImpl, ServiceMock + DI, если втупую

А метод внутри scala object может?

По-моему, лучше просто не нужно так писать, чтобы потом нужно было object'ы мокать :)

Ну, object HttpWeb {def getUriAsString(uri): Future[String]).

Как замокать?

а надо ли?)

Товарищи подскажите такую штуку, могу ли я использовать аковские стримы вместо Rx, типо у меня Subject, в котором переодически меняется значение и это рассасывается? Я чо то не смог найти ничего подобного

а надо ли?)

Дык, я хочу тестировать бизнес-логику,которая делает запросы, используя этот метод объявленный в HttpWeb. Зачем мне делать *реальные* запросы к сервису?

мокай сервис тогда

Почему HttpWeb - это объект, а не класс?

Вот основной вопрос

Мне как-то надо было замокать апи amazon s3. Я что-то выпил, потом как в тумане все. Очнулся - а там уже 50 звёзд на гитхабе: https://github.com/findify/s3mock

Почему HttpWeb - это объект, а не класс?

А зачем его инстанциировать каждый раз, когда нужно использовать только одну функцию?

Не надо его инстанциировать каждый раз. Достаточно 1 раз как синглтон

По-моему, много статей было же, почему плохо писать логику в статических методах

@clayrat спасибо!

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

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

Не надо его инстанциировать каждый раз. Достаточно 1 раз как синглтон

А разве object - это не синглтон? Так я бизнес-логику то не пишу в статических классах. Я в object написал 1 обертку-функцию над akka-http. Затем, уже в логике ее использую. Я просто хочу замокать эту функцию, чтобы не звать akka-http

клиент использует эту штуку http://kazuhiro.github.io/scala/akka/akka-http/akka-streams/2016/01/31/connection-pooling-with-akka-http-and-source-queue.html то есть нужно только хост прописать

Допусти, так object HttpWeb { private val STRICT_ENTITY_TIMEOUT = 999.days def getUriAsString(uri: Uri) (implicit system: ActorSystem, materializer: ActorMaterializer ): Future[String] = { val resp = Http().singleRequest(HttpRequest(uri = uri)) resp flatMap { r => if (r.status == StatusCodes.OK) { r.entity.toStrict(STRICT_ENTITY_TIMEOUT).map(_.data.utf8String) } else { r.entity.discardBytes() Future.failed( new Exception(s"Remote server at $uri has returned status code: ${r.status.value}")) } } } }

гисты и прочие сервисы делают код намного читаемее

Нет, ну мое дело посоветовать :)

дао тоже через обджект пишешь? бизнес-логика там не пишется, возвращается фьюча, туда-сюда

https://stackoverflow.com/questions/26811401/scala-override-a-class-method-in-a-trait вот так не лету в тесте переопределить обьект клиента, на фековый клиент

но это опять какое-то кунг-фу

наверно правильней инжектить это всё через конструкторы и тд и тп

дао тоже через обджект пишешь? бизнес-логика там не пишется, возвращается фьюча, туда-сюда

Если существует возможность, что кусок кода может иметь несколько реализаций, то лучше определить спецификацию и вынести в trait. А классом уже имплементить это trait и писать одну из реализаций

У меня плохие новости. Если пишутся юнит-тесты, то почти для всех "кусков кода" есть как минимум две реализации - реальная и тестовая

Изначальный вопрос был не в том, как проектировать архитектуру программы. А в том, какую либу кто использует для мокания внешних сервисов. Может быть имеется стандарт де-факто в Scala мире. Например, в Java - это Mockito

мокито вполне годно юзается и в скале

Ситуация: доступ в инет через прокси, поднят нексус, который проксирует некоторый набор реп, сбт глобально добавлен резолвер на нексусовые прокси-репы. Беда: зависимости для сбт плагина выкачиваются вечность, так как сначала они ищутся по внешним репам (которые недоступны), а затем лишь резолвятся в нексусе. Вопрос: как сбт отрезать все тентакли, которые лезут куда-либо, кроме нексуса?

Вписать nexus в ~/.sbt/repositories

А то на каждой "сокет нот коннектед" уходит по 10 секунд ожидания. Наверно уже минут 20 резолвит все для sbt-assembly

мокито вполне годно юзается и в скале

Ok. А про ScalaMock что думаешь?

Ok. А про ScalaMock что думаешь?

Ничего

Вписать nexus в ~/.sbt/repositories

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

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

Это даже в доках говорится

This repositories file is all that’s required to use a proxy repository. These repositories will get included first in any sbt build

Реальность иная

Стандартные репозитории это не исключило

У меня тоже nexus и зависимости качаются именно оттуда :)

Хм. Может я еще какой-то репозиторий недоуказал. Как же больно за проксей :(

В сбт можно переопределить порядок резолверов

Изначальный вопрос был не в том, как проектировать архитектуру программы. А в том, какую либу кто использует для мокания внешних сервисов. Может быть имеется стандарт де-факто в Scala мире. Например, в Java - это Mockito

Делаем заглушки как отдельный сервис...

Как я понял, можно сделать какой-нибудь global.sbt и там все вырезать

У меня сейчас артефакты для sbt-assembly резолвились полчаса, каждый выдавал по 2 ошибки Socket is not connected по внешнему адресу. А в конце все радостно скачалось с нексуса)

я делал таким костылем: appResolvers := appResolvers.value.map(_.filter { case _: FileRepository => true case _ => false }), resolvers ++= Seq( "my proxy repo" at "http://proxy.nexus.mycompany.com/public/", DefaultMavenRepository, "Maven Central Server" at "http://central.maven.org/maven2", ... )

Во, как-то так и я сейчас попробую, спасибо)

после первого резолвинга и кэширования локально и/или на прокси ничего потом нигде снаружи не ищется

Делаем заглушки как отдельный сервис...

Ок. Я в принципе пришел к следующему решению. trait HttpWebSpec { def someMethod } object HttpWeb extends HttpWebSpec { .... implementation of the trait above.. } А уже в unit-test'ах мокаю HttpWebSpec - mock[HttpWebSpec], через when(..).return(...) описываю желаемое поведение. Использую ScalaMock.

ERROR: S client not available

Ну, вот. Это уже гораздо лучше, чем пытаться мокать объект

?

Я в unit-тестах тестирую только простые функции, без обращения к сервисам... Сервисы и собственно говоря бизнес логика потом тестируются отдельно на заглушках ...

Я в unit-тестах тестирую только простые функции, без обращения к сервисам... Сервисы и собственно говоря бизнес логика потом тестируются отдельно на заглушках ...

Это извечная holy-war, что лучше mockать или stubить. Кому что нравится) Главное, чтобы код был протестирован)

Это извечная holy-war, что лучше mockать или stubить. Кому что нравится) Главное, чтобы код был протестирован)

Главное чтобы работал ?

кто тестирует, тот не пьет шампанского)

Вопрос по тестированию. Кто как тестирует бизнес-логику, которая взаимодействует с внешними сервисами, например делает запросы к REST-API или к БД? Кто чем мокает (mock) такие сервисы? ScalaMock ?

фриманатки

фриманатки

Можешь привести пример. Очень интересно. Не слишком ли это overkill для тестов?

а какой CI в скале модно использовать?

а какой CI в скале модно использовать?

модно или можно?

модно

Да.

hudson?

на можно / не можно мне пофиг )

@rockjam мне сервис

опенсорсные проекты на гитхабе собираются тревисом и circle, еще дрон

как и везде travic ?

circle

кажется он моднее

ок, то чего-то "своего" нет

akka-CI

которое с sbt / ide / чем-то там ещё дружит

Можешь привести пример. Очень интересно. Не слишком ли это overkill для тестов?

Предположим ты имеешь такой сервис, сделанный, конечно же с помощью наиболее продвинутой либы https://github.com/aecor/liberator @free trait Service[F[ ]]{ def foo(): F[Foo] def bar(x: F[Foo]): F[Bar] }

shapeless-CI - опиши конфигурации HList-ами и Record-ами

которое с sbt / ide / чем-то там ещё дружит

ну, дружба с sbt - это просто запустить

с IDE дружит teamcity

teamcity дружит c sbt из коробки

из коробки и circle и travis дружат вроде

teamcity так и не превратили в сервис

ну слушай, если тебе тревис привычен - бери его. если хочешь что-то новое изучить, то не знаю, circle

Можешь привести пример. Очень интересно. Не слишком ли это overkill для тестов?

У тебя есть продакшновый интепретатор для какой-нибудь Future или там Task Возможно даже его реализация выглядит как-то так implicit def serviceImpl[F[ ]: Req1 : Req2] = new Service[F]{ ... }

Travis CI currently does not support git repositories hosted on Bitbucket or GitLab, or other version control systems such as Mercurial.