util

This library is available on Maven Central and on our public Bintray repository, found at: https://dl.bintray.com/outworkers/oss-releases/.

It is publicly available, for both Scala 2.10.x and Scala 2.11.x. Check the badges at the top of this README for the latest version of util available. The badges are automatically updated when a new version is out, this readme is not.

Table of contents

1. Integrating the util library

2. util-parsers

   • Option parsers
   • Applicative parsers

3. util-parsers-cats

   • Option parsers
   • Applicative parsers

4. util-testing

   • Async assertions
   • Data sampling
   • Automated sampling

5. util-zookeeper

   • ZooKeeperInstance
   • Copyright
   • Scala Style Guidelines
   • Git Flow
   • Contributing
   • Copyright

Integrating the util library

Back to top

The util library is designed to wrap common functionality in all our frameworks and offer it at the convenience of a dependency. Anything that will be useful long term to a great number of people belongs in these modules, to avoid duplication and help make our devs aware they can simply use what already exists.

The full list of available modules is:

libraryDependencies ++= Seq(
  "com.outworkers" %% "util-lift" % Versions.util,
  "com.outworkers" %% "util-domain" % Versions.util,
  "com.outworkers" %% "util-parsers" % Versions.util,
  "com.outworkers" %% "util-parsers-cats" % Versions.util,
  "com.outworkers" %% "util-validators" % Versions.util,
  "com.outworkers" %% "util-validators-cats" % Versions.util,
  "com.outworkers" %% "util-play" % Versions.util,
  "com.outworkers" %% "util-urls" % Versions.util,
  "com.outworkers" %% "util-testing" % Versions.util
)

util-testing

Back to top

The testing module features the AsyncAssertionsHelper, which builds on top of ScalaTest to offer simple asynchronous assertions. We use this pattern heavily throughout the Outworkers ecosystem of projects, from internal to DSL modules and so forth. Asynchronous testing generally offers a considerable performance gain in code.

Async assertions

Back to top

The async assertions module features a dual API, so you can call the same methods on both scala.concurrent.Future and com.twitter.util.Future. The underlying mechanism will create an async Waiter, that will wait for the future to complete within the given PatienceConfiguration. The awaiting is done asynchronously and the assertions are invoked and evaluated once the future in question has returned a result.

import com.outworkers.util.testing._

class MyTests extends FlatSuite with Matchers {

  "The async computation" should "return 0 on completion" in {
    val f: Future[Int] = .. // Pretend this is a Future just like any other future.
    f.successful {
      res => {
        res shouldEqual 0
      }
    }
  }
  
  "This async computation" should "fail by design" in {
    val f: Future[Unit] = ..
    
    // You don't even need to do anything more than failure at this stage.
    // If the Future fails, the test will succeed, as this method is used when you "expect a failure".
    // You can however perform assertions on the error returned.
    f.failing {
      err => {
      }
    }
  }
  
  "This async computation" should "fail with a specific error" in {
      val f: Future[Unit] = ..
      f.failingWith[NumberFormatException] {
        err => {
        }
      }
    }

}

You can directly customise the timeout of all Waiters using the ScalaTest specific time span implementations and interval configurations.

import org.scalatest.concurrent.PatienceConfiguration
import org.scalatest.time.SpanSugar._

implicit val timeout: PatienceConfiguration.Timeout = timeout(20 seconds)

Summary:

• The dependency you need is "com.outworkers" %% "util-testing" % UtilVersion.
• You have to import com.outworkers.util.testing._.
• You have three main assertion methods, successful, failing, and failingWith.
• You can configure the timeout of waiters with implicit val timeout: PatienceConfiguration.Timeout = timeout(20 seconds).
• The default timeout value is 1 second.

Data sampling

Back to top

This is a very common pattern we use in our testing and it's very easy to interchange this generation with something like ScalaCheck. The idea is very simple, you use type classes to define ways to sample a given type. After you define such a one-time sampling type class instance, you have access to several methods that will allow you to generate test data.

It's useful to define such typeclass instances inside package objects, as they will be "invisibly" imported in to the scope you need them to. This is often really neat, albeit potentially confusing for novice Scala users.

import com.outworkers.util.testing._

@sample case class MyAwesomeClass(name: String, age: Int, email: String)

You may notice this pattern is already available in better libraries such as ScalaMock and we are not trying to provide an alternative to ScalaMock or compete with it in any way. Our typeclass generator approach only becomes very useful where you really care about very specific properties of the data. For instance, you may want to get a user with a valid email address, or you may use the underlying factories to get a name that reassembles the name of a real person, and so on.

It's also useful when you want to define specific ways in which hierarchies of classes are composed together into a sample. If generation for the sake of generation is all you care about, then ScalaMock is probably more robust.

Automated sampling

Back to top

One interesting thing that happens when using the @sample annotation is that using gen immediately after it will basically give you an instance of your case class with the fields appropiately pre-filled, and some of the basic scenarios are also name aware.

What this means is that we try to make the data feel "real" with respect to what it should be. Let's take the below example:

@sample case class User(
  id: UUID,
  firstName: String,
  lastName: String,
  email: String
)

This is interesting and common enough. What's more interesting is the output of gen.

val user = gen[User]

Console.println(user.trace())

/**
User(
  id = 6be8914c-4274-40ee-83f5-334131246fd8
  firstName = Lindsey
  lastName = Craft
  email = rparker@hotma1l.us
)
*/

So as you can see, the fields have been appropriately pre-filled. The email is a valid email, and the first and last name look like first and last names. For anything that's in the default generation domain, including dates and country codes and much more, we have the ability to produce automated appropriate values.

During the macro expansion phase, we check the annotation targets and try to infer the "natural" value based on the field name and type. So if your field name is either "email" or "emailAddress" or anything similar enough, you will get an "email" back.

Generating data

There are multiple methods available, allowing you to generate more than just the type:

• gen[T], used to generate a single instance of T.
• gen[X, Y], used to generate a tuple based on two samples.
• genOpt[T], convenience method that will give you back a Some[T](..).
• genList[T](limit), convenience method that will give you back a List[T]. The numbers of items in the list is equal to the limit and has a default value of 5 if not specified.
• genMap[T](), convenience method that will give you back a Map[String, T].

There is also a default list of available generators for some default types, and to get to their value simply use the value method if the type is not a primitive. For things like EmailAddress, the point of the extra class is obviously to distinguish the type during implicit resolution, but you don't need to use our abstraction at all, there will always be an easy way to get to the underlying generated primitives.

In the case of email addresses, you can use gen[EmailAddress].value, which will correctly generate a valid EmailAddress but you can work directly with a String.

• scala.Int
• scala.Double
• scala.Float
• scala.Long
• scala.String
• scala.math.BigDecimal
• scala.math.BigInt
• java.util.Date
• java.util.UUID
• org.joda.time.DateTime
• org.joda.time.LocalDate
• com.outworkers.util.domain.Definitions.EmailAddress(value)
• com.outworkers.util.domain.Definitions.FirstName(value)
• com.outworkers.util.domain.Definitions.LastName(value)
• com.outworkers.util.domain.Definitions.FullName(value)
• com.outworkers.util.domain.Definitions.CountryCode(value)
• com.outworkers.util.domain.Definitions.Country(value)
• com.outworkers.util.domain.Definitions.City(value)
• com.outworkers.util.domain.Definitions.ProgrammingLanguage(value)
• com.outworkers.util.domain.Definitions.LoremIpsum(value)

util-parsers

Back to top

The parser module features an easy to use and integrate set of ScalaZ Applicative based parsers, with an Option based parser variant. It allows us to seamlessly deal with validation chains at REST API level or whenever validation is involved. Whether it's monadic composition of options or chaining of applicative functors to obtain a "correct" chain, the parser module is designed to offer an all-you-can-eat buffet of mini parsers that can be easily composed to suit any validation needs.

Each parser comes in three distinct flavours, a ValidationNel parser that parsers the end type from a String and returns the type itself, a parser that parses an end result from an Option[String] and parserOpt variant that returns an Option[T] instead of a ValidationNel[String, T], which allows for Monadic composition, where you need to "short-circuit" evaluation and validation, instead of computing the full chain by chaining applicatives.

Option parsers

Back to top

The full list of optional parsers is:

Option parsers are designed for chains where you want to short-circuit and exit to result as soon a parser fails. This short-circuit behaviour is the default flatMap behaviour of an Option, as soon as an Option is None the chain breaks. Unlike applicatives, the evaluation sequence of options will be escaped and you cannot for instance return an error for every parser that couldn't validate. Instead, you will only get the first error in the sequence.

An example of how to use Option parsers might be:

import com.outworkers.util.parsers._

object Test {
  def optionalParsing(email: String, age: String): Unit = {
    for {
      validEmail <- parseOpt[EmailAddress](email)
      validAge <- parseOpt[Int](age)
    } yield s"This person can be reached at $validEmail and is $validAge years old"
  }
}

Applicative parsers

Back to top

The full list of ScalaZ Validation based applicative parsers is:

To illustrate the basic usage of applicative parsers and how to chain them, have a look below.

import scalaz._
import scalaz.Scalaz._
import com.outworkers.util.parsers._

object Test {
  
  def registerUser(str: String, age: String): Unit = {
    (parse[EmailAddress](str) |@| parse[Int](age)) {
      (validEmail, validAge) => {
      }
    }.fold {
      // .. 
    }
  }
  
}

Contributors

Back to top

• Flavian Alexandru @alexflav23
• Jens Halm @jenshalm
• Bartosz Jankiewicz @bjankie1

Copyright

Back to top

Copyright (c) 2014 - 2016 outworkers.