There are two specs here. First is not passing because eventually in check will not cause whole route rerun but this is the way I would prefer to follow. The second spec is the best solution I found (and prove that it is doable ;) ) but it contains some boilerplate like additional function which in real life will have to return rather tuple than single thing and it is inconsistent with spray-tests syntax design to test routs.
So question is:
How to use eventually with spray-tests to be as close as possible to syntax from first spec.
import org.specs2.mutable.Specification
import spray.routing.Directives
import spray.http._
import MediaTypes._
import HttpCharsets._
import spray.testkit.Specs2RouteTest
class EventuallyAndRouts extends Specification with Directives with Specs2RouteTest {
var i = 0
def incAndGet = {
i = i + 1
println(s"This is i = $i")
s"$i"
}
"The testing infrastructure should support an eventually matcher" >> {
"but it is not working inside a check as I need :( (and this will fail)" in {
i = 0
Get() ~> complete(incAndGet) ~> check {
body must eventually(7, 20 millis)(be_===(HttpEntity(ContentType(`text/plain`, `UTF-8`), "5")))
}
}
"so I got workaround :/ (and this is passing)" in {
i = 0
def requestResult = Get() ~> complete(incAndGet) ~> check {
body
}
requestResult must eventually(7, 20 millis)(be_===(HttpEntity(ContentType(`text/plain`, `UTF-8`), "5")))
}
}
}
eventually is used to evaluate repeatedly a value that is changing. So it either has to be a var, a def or a byname parameter.
The best way around that is probably for you to implement a checkEventually(times, delay) method that will incorporate the eventually call. Something like that:
implicit class Checked(request: =>Request) {
def checkEventually[R : AsResult](times: Int, delay: Duration, matcher: Matcher[RequestResult])(body: =>Unit)( = {
val requestResult = result ~> check(body)
requestResult must eventually(times, delay)(matcher)
}
}
Related
I am working on a todo list app using
scalajs,
cats (free monads), and
scalajs-react
When I am using a simple model like the code below, everything works like expected.
class TodoModel() {
private object State {
var todos = Seq.empty[Todo]
def mod(f: Seq[Todo] => Seq[Todo]): Callback = {
val newTodos = f(todos)
Callback(todos = newTodos)
}
}
def add(t: Todo): Callback = State.mod(_ :+ t)
def todos: Seq[Todo] = State.todos
}
Once I use the free monads from cats, I have an odd behaviour. The first click always inserts two todo entries. Every click afterwards works like expected. See the pictures below.
What is wrong here?
import cats.free.Free
import cats.free.Free.liftF
import japgolly.scalajs.react._
import japgolly.scalajs.react.vdom.html_<^._
import org.scalajs.dom
case class Todo(text: String)
sealed trait TodoModelOp[A]
case class Add(todo: Todo) extends TodoModelOp[Unit]
case class Todos() extends TodoModelOp[Seq[Todo]]
object FreeTodoModelOps {
// type alias for lifted TodoModelOp
type TodoModelOpF[A] = Free[TodoModelOp, A]
def add(Todo: Todo): TodoModelOpF[Unit] = liftF[TodoModelOp, Unit](Add(Todo))
def todos: TodoModelOpF[Seq[Todo]] = liftF[TodoModelOp, Seq[Todo]](Todos())
}
object StateInterpreter {
import cats.arrow.FunctionK
import cats.{ Id, ~> }
val interpet: TodoModelOp ~> Id = new (TodoModelOp ~> Id) {
val todos = scala.collection.mutable.ArrayBuffer.empty[Todo]
def apply[A](fa: TodoModelOp[A]): Id[A] = fa match {
case Add(todo) => todos += todo; ()
case Todos() => todos.toSeq
}
}
}
class TodoModel() {
import cats.instances.list._
import cats.syntax.traverse._
import FreeTodoModelOps._
def add(t: Todo): Callback = {
def program: TodoModelOpF[Unit] = for {
_ <- FreeTodoModelOps.add(t)
} yield ()
Callback(program.foldMap(StateInterpreter.interpet))
}
def todos: Seq[Todo] = {
def program: TodoModelOpF[Seq[Todo]] = for {
n <- FreeTodoModelOps.todos
} yield n
program.foldMap(StateInterpreter.interpet)
}
}
object TodoPage {
case class Props(model: TodoModel)
case class State(todos: Seq[Todo])
class Backend($: BackendScope[Props, State]) {
val t = Todo("a new todo")
def onSubmit(e: ReactEventFromInput) =
e.preventDefaultCB >>
$.modState(s => State(s.todos :+ t)) >>
$.props.flatMap(P => P.model.add(t))
def render(S: State) =
<.div(
<.form(
^.onSubmit ==> onSubmit,
<.button("Add #", S.todos.length + 1)),
<.ul(S.todos.map(t => <.li(t.text)): _*))
}
val component = ScalaComponent.builder[Props]("Todo")
.initialStateFromProps(p => State(p.model.todos))
.renderBackend[Backend]
.build
def apply(model: TodoModel) = component(Props(model))
}
object Test {
val model = new TodoModel()
def main(args: Array[String]): Unit = {
TodoPage.apply(model).renderIntoDOM(dom.document.getElementById("mount-node"))
}
}
empty, no click on button
first click on button
second click on button
In your first snippet there's a bug:
Here you've got a variable todos (inpure) which you're accessing in a pure context:
def mod(f: Seq[Todo] => Seq[Todo]): Callback = {
val newTodos = f(todos)
Callback(todos = newTodos)
Impurity should be in Callback. Even reading a variable outside of a Callback is unsafe, so it should be:
def mod(f: Seq[Todo] => Seq[Todo]): Callback =
Callback(todos = f(todos))
(See scalajs-react's Ref.scala an example of safely working with a variable.)
Secondly, with regards to your larger snippet, scalajs-react is very FP friendly but that's very unconventional way of trying to use it, and has some significant problems:
StateInterpreter.interpet isn't referentially-transparent; there's shared global state underlying that. Fails the FP test. Stops being a lawful natural transformation.
You're tracking two sets of identical state separately: the component state and the state in TodoModel (impure, fails the FP test). Not only is this approach redundant and runs the risk of the two states getting out-of-sync, but it also makes the component less reusable; imagine you decided to draw it twice on the same screen for the same data - they're going to go out of sync. Best to keep the component stateless and pure.
If you're going to transform a free structure into a component effect, it's best to transform it into a state monad, see here for an example.
It's really, really awesome that you're learning about free monads and scalajs-react. FP will make your entire program really, really easy to reason about and prevent confusing surprises in behaviour, but you've got to not cut any corners and make sure that you keep all of your code pure. Any impurity will render the entire stack all the way up to the entrypoint impure and remove those nice dependable FP properties from those layers. I'd suggest making everything as pure as possible using the points above as starting points, and then I think you'll find that the bug just disappears, or at least is very easy to then detect. Cheers
What to return on success in add ?
Currently I return Unit, is there a more idiomatic way ?
I mean, the Either[String, Unit] does not feel right, because Right is meant to return a value, since it has a type parameter.
The method can fail or complete with success, however when it completes with success then there is nothing to return, so I just return Right(). I wonder what is the idiomatic way to describe such situation?
What would be a good type to represent this situation ?
import scala.collection.immutable.HashMap
import scala.concurrent.ExecutionContext
object UUID{
def apply():UUID= UUID(java.util.UUID.randomUUID().toString)
}
case class UUID(id:String) case class Ref[T](c:Class[T], id:UUID) {
override def equals(that:Any)=id.equals(that)
override def hashCode()=id.hashCode()
}
case class RefVal[T](r:Ref[T],v:T)
package container {
import scala.concurrent.Future
trait MapContainer[T] {
var map: HashMap[Ref[T], RefVal[T]] = HashMap[Ref[T], RefVal[T]]();
private[container] def add(rv: RefVal[T]): Future[Either[String, Unit]] = Future
{
if (!map.contains(rv.r)) {
map = map updated(rv.r, rv)
Right()
} else Left("add, class already exists with this uuid :" + rv.r.c)
}
private[container] def notExposed=println("cannot run this from outside package 'model'")
def delete(r:Ref[T]) : Future[Either[String,Unit]]= Future {
if (map.contains(r))
{
map = map - r
Right()
}
else Left(r+"element not found")
}
...
}
I think a more idiomatic way would be :
Create a custom exception class for your exception case (arguable)
Return an Either[Throwable, Map] in the add method, returning the modified map on the right side
Btw, you can use codereview.stackexchange for, well, code review needs :)
Edit : as #massg pointed, at this point, Try[Map] has exactly the semantic of Either[Throwable, Map], and is indeed more weel suited
I'd like to test a method that returns a Future. My attempts were as follows:
import org.specs2.mutable.Specification
import scala.concurrent.ExecutionContext.Implicits.global
import scala.util.{Failure, Success}
class AsyncWebClientSpec extends Specification{
"WebClient when downloading images" should {
"for a valid link return non-zero content " in {
val testImage = AsyncWebClient.get("https://www.google.cz/images/srpr/logo11ww.png")
testImage.onComplete { res =>
res match {
case Success(image) => image must not have length(0)
case _ =>
}
AsyncWebClient.shutDown
}
}
}
}
Apart from the fact that I am unable to make this code work I guess that there could be a better way of testing a futures with a Future-oriented matcher.
How to do it properly in specs2?
You can use the Matcher.await method to transform a Matcher[T] into a Matcher[Future[T]]:
val testImage: Future[String] =
AsyncWebClient.get("https://www.google.cz/images/srpr/logo11ww.png")
// you must specify size[String] here to help type inference
testImage must not have size[String](0).await
// you can also specify a number of retries and duration between retries
testImage must not have size[String](0).await(retries = 2, timeout = 2.seconds)
// you might also want to check exceptions in case of a failure
testImage must throwAn[Exception].await
Took me awhile to find this so thought I'd share. I should've read the release notes. In specs2 v3.5, it is required to use implicit ExecutionEnv to use await for future. This can also be used for future transformation (i.e. map) see http://notes.implicit.ly/post/116619383574/specs2-3-5.
excerpt from there for quick reference:
import org.specs2.concurrent.ExecutionEnv
class MySpec extends mutable.Specification {
"test of a Scala Future" >> { implicit ee: ExecutionEnv =>
Future(1) must be_>(0).await
}
}
Await is an anti pattern. Shouldn't ever use it.
You can use traits like ScalaFutures, IntegrationPatience, and Eventually.
whenReady does the magic you are looking for.
Example:
import org.specs2.mutable.Specification
import scala.concurrent.ExecutionContext.Implicits.global
import scala.util.{Failure, Success}
import org.scalatest.concurrent.{IntegrationPatience, ScalaFutures}
import scala.concurrent.Future
class AsyncWebClientSpec extends Specification
with ScalaFutures
with IntegrationPatience {
"WebClient when downloading images" should {
"for a valid link return non-zero content " in {
whenReady(Future.successful("Done")){ testImage =>
testImage must be equalTo "Done"
// Do whatever you need
}
}
}
}
There is a nice thing for that in specs2 - implicit await method for Future[Result]. If you take advantage of future transformations you can write like this:
"save notification" in {
notificationDao.saveNotification(notification) map { writeResult =>
writeResult.ok must be equalTo (true)
} await
}
Future composition comes to the rescue when some data arrangement with async functions is needed:
"get user notifications" in {
{
for {
_ <- notificationDao.saveNotifications(user1Notifications)
_ <- notificationDao.saveNotifications(user2Notifications)
foundUser1Notifications <- notificationDao.getNotifications(user1)
} yield {
foundUser1Notifications must be equalTo (user1Notifications)
}
} await
}
Note how we have to use an additional block around for-comprehension to convince compiler. I think it's noisy, so if we turn await method in a function we come up with a nicer syntax:
def awaiting[T]: Future[MatchResult[T]] => Result = { _.await }
"get user notifications" in awaiting {
for {
_ <- notificationDao.saveNotifications(user1Notifications)
_ <- notificationDao.saveNotifications(user2Notifications)
foundUser1Notifications <- notificationDao.getNotifications(user1)
} yield {
foundUser1Notifications must be equalTo (user1Notifications)
}
}
Wondering why #etorreborre did not mention "eventually"
See https://github.com/etorreborre/specs2/blob/master/tests/src/test/scala/org/specs2/matcher/EventuallyMatchersSpec.scala#L10-L43
class EventuallyMatchersSpec extends Specification with FutureMatchers with ExpectationsDescription { section("travis")
addParagraph { """
`eventually` can be used to retry any matcher until a maximum number of times is reached
or until it succeeds.
""" }
"A matcher can match right away with eventually" in {
1 must eventually(be_==(1))
}
"A matcher can match right away with eventually, even if negated" in {
"1" must not (beNull.eventually)
}
"A matcher will be retried automatically until it matches" in {
val iterator = List(1, 2, 3).iterator
iterator.next must be_==(3).eventually
}
"A matcher can work with eventually and be_== but a type annotation is necessary or a be_=== matcher" in {
val option: Option[Int] = Some(3)
option must be_==(Some(3)).eventually
}
onComplete returns Unit, so that block of code returns immediately and the test ends before being able to do anything. In order to properly test the result of a Future, you need to block until it completes. You can do so using Await, and setting a maximum Duration to wait.
import scala.concurrent._
import scala.concurrent.duration._
Await.result(testImage, Duration("10 seconds")) must not have length(0)
I've googled this and cannot find an answer.
I want to make a GET to a url in Scala/play framework and then do something with the result. If the result contains what I want then I want to call it again with some other parameter. And this could be up to like 100 times so I can't nest several WS's. I want like a loop to do the same call over and over again till I find what I'm looking for but when I wrap all this code below in a loop it dosen't wait for each call to finish, which i understand. But how can I solve this?
var index = 0
val call = WS.url("http://urlToGetSomethingFrom¶meter="+index).get()
for{
response <- call
} yield{
val something: String = response.json / "name"
if(something.equals("Eric")){
//I'm finished, break out
}else{
index += 1
//and then I want to do the same call again
}
}
get() returns a Future.
In order to wait for it to finish, you need to pass it to Await.result along with an expiration duration.
Example here: https://stackoverflow.com/a/16296848/604041
I think this is basically the same as #MartinGotzke's answer. I haven't actually tried to compile this or anything, but hopefully it helps ... Good luck!
/** Keep looking until you find Eric */
def findEric( index:Int ):Future[Response] = {
WS.url("http://urlToGetSomethingFrom¶meter="+index).get(
).flatMap(
(resp) => if( resp.json / "name" == "Eric" ) Promise.successful( resp ).future
else findEric( index+1 )
)
}
findEric(0).onComplete( (resp) => { /* whatever it is you really want to do */ } )
Here's a solution that does not use blocking.
The key is that it's using a recursive call and that it uses flatMap and returns Promise.pure for the desired result.
As it's an actually working sample using the old google search api, it's a little bit more complicated because there's a list/Seq of titles that's mapped and checked against the predicate function.
package controllers
import play.api._
import play.api.mvc._
import play.api.libs.concurrent.Promise
import play.api.libs.json._
import play.api.libs.ws.WS
import scala.concurrent.Future
import scala.concurrent.ExecutionContext.Implicits.global
object Application extends Controller {
def index = Action {
def callWS(index: Int, f: String => Boolean): Future[String] = {
WS.url("https://ajax.googleapis.com/ajax/services/search/web")
.withQueryString(("v", "1.0"), ("q", "foo" + index)).get
.flatMap { response =>
val titles = (response.json \ "responseData" \ "results" \\ "title")
titles.map(_.as[String]).find(f(_)).map(Promise.pure(_)).getOrElse(callWS(index + 1, f))
}
}
Async(callWS(0, _.contains("FOO-1")).map(Ok(_)))
}
}
Here's another example written in Scala by the Play team for the Techempower benchmarks
https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/play-scala/app/controllers/Application.scala#L44
I have the following scala code:
package dummy
import javax.servlet.http.{HttpServlet,
HttpServletRequest => HSReq, HttpServletResponse => HSResp}
import scala.actors.Actor
class DummyServlet extends HttpServlet {
RNG.start
override def doGet(req: HSReq, resp: HSResp) = {
def message = <HTML><HEAD><TITLE>RandomNumber </TITLE></HEAD><BODY>
Random number = {getRandom}</BODY></HTML>
resp.getWriter().print(message)
def getRandom: String = {var d = new DummyActor;d.start;d.getRandom}
}
class DummyActor extends Actor {
var result = "0"
def act = { RNG ! GetRandom
react { case (r:Int) => result = r.toString }
}
def getRandom:String = {
Thread.sleep(300)
result
}
}
}
// below code is not modifiable. I am using it as a library
case object GetRandom
object RNG extends Actor {
def act{loop{react{case GetRandom=>sender!scala.util.Random.nextInt}}}
}
In the above code, I have to use thread.sleep to ensure that there is enough time for result to get updated, otherwise 0 is returned. What is a more elegant way of doing this without using thread.sleep? I think I have to use futures but I cannot get my head around the concept. I need to ensure that each HTTP reaquest gets a unique random number (of course, the random number is just to explain the problem). Some hints or references would be appreciated.
Either use:
!! <-- Returns a Future that you can wait for
or
!? <-- Use the one with a timeout, the totally synchronous is dangerous
Given your definition of RNG, heres some REPL code to verify:
scala> def foo = { println(RNG.!?(1000,GetRandom)) }
foo: Unit
scala> foo
Some(-1025916420)
scala> foo
Some(-1689041124)
scala> foo
Some(-1633665186)
Docs are here: http://www.scala-lang.org/api/current/scala/actors/Actor.html