2. @marcinerdmann
• Groovy enthusiast since 2010
• open source contributor
• Geb lead
• Ratpack committer
• testing junkie
• part of the Energized Work crew
3. What I won’t talk about
• Promises
• Execution model
– http://tinyurl.com/ratpack-execution-1
– http://tinyurl.com/ratpack-execution-2
• Handlers
• Handler chains
4. What I will talk about
• Development time reloading
• Deploying to the cloud
• Testing
• Configuration
• Application lifecycle
• Renderers and parsers
• Session support
5. Development time reloading
• Based on Gradle continuous mode
• Enabled by –t/--continuous switch
• Server restart is performed on change
• Only user classes are reloaded
• Detects any changes in the build
7. Deploying to heroku
• Given:
– JDK
– Gradle
– Heroku toolbelt
• In ~7min from zero to deployment
• Heroku’s Gradle example is a ratpack app
– heroku/gradle-getting-started on github
8. ApplicationUnderTest
• SAM interface that provides app URI
• Has a default method for creating
TestHttpClient pointing at the app
• Default implementations are lazy
– MainClassApplicationUnderTest
– GroovyRatpackMainApplicationUnderTest
• CloseableApplicationUnderTest
works well with @AutoCleanup
9. GroovyEmbeddedApp
• Useful for trying out ideas in the same file
as the test
• Useful for mocking out external http services
• Can be used to integration test classes as part of
a running application - Handlers, Chains,
Services, Renderers, Parsers, SessionsStores, etc
11. Impositions
• Useful in moulding application under test
• Allow control over configuration and registries
• No need to modify production code
• New in 1.2.0
12. Configuration
• Many built in config sources (json, yaml
and property files, environment, system
properties, command line args)
• Parsed into a tree of Jackson ObjectNodes
• Mapped into objects that are available
from the registry
• Mapped using Jackson ObjectMapper
• Easily changed at test time via imposition
13. Custom config sources
• Create your own config source if needed
• Implement ratpack.config.ConfigSource
• Add using ServerConfigBuilder.add()
• Useful when overriding config in tests
15. Remote control
• Useful for gray box testing
• Useful when setting up internal state
before test
• Useful when verification of state would be
tedious if using app’s public interfaces
• Built in support in Ratpack
• Easily enabled in tests via imposition
16. Renderers
• Strategy classes for rendering http
responses from different objects
• Used with Context.render(Object)
• Builtin renderers for CharSequence, Path,
json, Promise, Renderable, various
templates
• Add your own by implementing Renderer
or extending RendererSupport
18. RenderableDecorator
• Allow to decorate rendered objects
• Sit between Context.render(Object)
Renderer.render(Context, Object)
• Useful for adding default values to
template models
• Add your own by implementing
RenderableDecorator or extending
RenderableDecoratorSupport
19. Parsers
• Strategy classes for parsing http requests
into objects
• Used with Context.parse(Class)
• Builtin renderers for json and http forms
• Add your own by implementing Parser or
extending ParserSupport
20. Sessions
• Designed with support for distributed
sessions in mind
• Built-in store implementations: in
memory, cookie based, redis backed
• Build your own – file backed store example
in javadoc for SessionStore interface
21. Sessions
• By default serialized using Java
serialization
• Customize by implementing
SessionSerializer and putting it in the
registry
22. Services
• Can participate in application lifecycle
– onStart(StartEvent)
– onStop(StopEvent)
• Implement ratpack.server.Service
• Put them in registry
23. Integrate over abstract
• ratpack-tymeleaf, ratpack-handlebars vs
ratpack-template
• ratpack-hikari vs ratpack-connection-pool
• ratpack-pac4j vs ratpack-security
• ratpack-dropwizard-metrics,
ratpack-hystrix, ratpack-rx
• registry is abstracted hence Ratpack can be
used with Guice, Spring or none
• good strategy if you’re in for a long run