You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Adding tut plugin
* Add in readme for the project
* Updating the documentation to use tut
* Adding examples of how to derive new types.
* Simplifying the logic with env variables
* Removing assertions test as assertions have been removed.
* Updating patience configuration
* Adding environment exports
* Trying to fix Travis logic
* Adding docs folder output
* Changing entrypoint into readme
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
61
-
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 testing module features the ```AsyncAssertionsHelper```, which builds on top of ScalaTest to offer simple asynchronous assertions. We use this pattern
85
-
heavily throughout the Outworkers ecosystem of projects, from internal to DSL modules and so forth. Asynchronous testing generally offers a considerable
86
-
performance gain in code.
87
-
88
-
89
-
### Async assertions ###
90
-
<ahref="#table-of-contents">Back to top</a>
91
-
92
-
93
-
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```.
94
-
The underlying mechanism will create an async ```Waiter```, that will wait for the future to complete within the given ```PatienceConfiguration```. The
95
-
awaiting is done asynchronously and the assertions are invoked and evaluated once the future in question has returned a result.
96
-
97
-
```scala
98
-
importcom.outworkers.util.testing._
99
-
100
-
classMyTestsextendsFlatSuitewithMatchers {
101
-
102
-
"The async computation" should "return 0 on completion" in {
103
-
valf:Future[Int] = .. // Pretend this is a Future just like any other future.
104
-
f.successful {
105
-
res => {
106
-
res shouldEqual 0
107
-
}
108
-
}
109
-
}
110
-
111
-
"This async computation" should "fail by design" in {
112
-
valf:Future[Unit] = ..
113
-
114
-
// You don't even need to do anything more than failure at this stage.
115
-
// If the Future fails, the test will succeed, as this method is used when you "expect a failure".
116
-
// You can however perform assertions on the error returned.
117
-
f.failing {
118
-
err => {
119
-
}
120
-
}
121
-
}
122
-
123
-
"This async computation" should "fail with a specific error" in {
124
-
valf:Future[Unit] = ..
125
-
f.failingWith[NumberFormatException] {
126
-
err => {
127
-
}
128
-
}
129
-
}
130
-
131
-
}
132
-
```
133
-
134
-
135
-
You can directly customise the ```timeout``` of all ```Waiters``` using the ScalaTest specific time span implementations and interval configurations.
- The dependency you need is ```"com.outworkers" %% "util-testing" % UtilVersion```.
149
-
- You have to import ```com.outworkers.util.testing._```.
150
-
- You have three main assertion methods, ```successful```, ```failing```, and ```failingWith```.
151
-
- You can configure the timeout of waiters with ```implicit val timeout: PatienceConfiguration.Timeout = timeout(20 seconds)```.
152
-
- The default timeout value is ```1 second```.
153
-
154
-
155
-
### Data sampling ###
156
-
<ahref="#table-of-contents">Back to top</a>
157
-
158
-
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.
159
-
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.
160
-
161
-
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.
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.
172
-
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.
173
-
174
-
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.
175
-
176
-
177
-
### Automated sampling
178
-
179
-
<ahref="#table-of-contents">Back to top</a>
180
-
181
-
One interesting thing that happens when using the `@sample` annotation is that using `gen` immediately after it will basically
182
-
give you an instance of your `case class` with the fields appropiately pre-filled, and some of the basic scenarios are also name aware.
183
-
184
-
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:
185
-
186
-
```scala
187
-
@sample caseclassUser(
188
-
id: UUID,
189
-
firstName: String,
190
-
lastName: String,
191
-
email: String
192
-
)
193
-
```
194
-
This is interesting and common enough. What's more interesting is the output of `gen`.
195
-
196
-
```scala
197
-
198
-
valuser= gen[User]
199
-
200
-
Console.println(user.trace())
201
-
202
-
/**
203
-
User(
204
-
id = 6be8914c-4274-40ee-83f5-334131246fd8
205
-
firstName = Lindsey
206
-
lastName = Craft
207
-
email = rparker@hotma1l.us
208
-
)
209
-
*/
210
-
211
-
```
212
-
213
-
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
214
-
anything that's in the default generation domain, including dates and country codes and much more, we have the ability to produce automated
215
-
appropriate values.
216
-
217
-
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
218
-
if your field name is either "email" or "emailAddress" or anything similar enough, you will get an "email" back.
219
-
220
-
221
-
### Generating data
222
-
223
-
There are multiple methods available, allowing you to generate more than just the type:
224
-
225
-
-```gen[T]```, used to generate a single instance of T.
226
-
-```gen[X, Y]```, used to generate a tuple based on two samples.
227
-
-```genOpt[T]```, convenience method that will give you back a ```Some[T](..)```.
228
-
-```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.
229
-
-```genMap[T]()```, convenience method that will give you back a ```Map[String, T]```.
230
-
231
-
232
-
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.
233
-
234
-
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```.
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
262
-
seamlessly deal with validation chains at REST API level or whenever validation is involved. Whether it's monadic composition of options or chaining of
263
-
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
264
-
composed to suit any validation needs.
265
-
266
-
Each parser comes in three distinct flavours, a ```ValidationNel``` parser that parsers the end type from a ```String``` and returns the type itself,
267
-
a parser that parses an end result from an ```Option[String]``` and parserOpt variant that returns an ```Option[T]``` instead of a ```ValidationNel[String,
268
-
T]```, which allows for Monadic composition, where you need to "short-circuit" evaluation and validation, instead of computing the full chain by chaining
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
287
-
```flatMap``` behaviour of an ```Option```, as soon as an ```Option``` is ```None``` the chain breaks. Unlike applicatives,
288
-
the evaluation sequence of options will be escaped and you cannot for instance return an error for every parser that couldn't validate. Instead,
289
-
you will only get the first error in the sequence.
290
-
291
-
An example of how to use ```Option``` parsers might be:
0 commit comments