Want to know what the hype surrounding JUnit 5 is all about? Then join this talk by JUnit 5 core committer Sam Brannen to find out!
Since JUnit 4.0 was first released, a lot has happened in the world of Java. Unfortunately, JUnit 4 hasn't kept up with the times. JUnit 5 therefore aims to help shape the future of testing on the JVM, with a focus on Java 8, modularity, extensibility, and a modern programming API for authoring tests in Java.
This presentation will start off by providing attendees an overview of the inspiration for and architecture of JUnit 5, from launchers to test engines. Sam will then take the audience on an example-driven tour of the new programming model, highlighting support for dependency injection via flexible method signatures, conditional test execution, using lambda expressions and method references in assertions and assumptions, and implementing test/before/after methods via interface default methods.
To round off the discussion, Sam will present an overview of the new extension model in JUnit 5, discussing how to author and register extensions for conditional tests, method parameter resolution, lifecycle callbacks, and more.
Shapes for Sharing between Graph Data Spaces - and Epistemic Querying of RDF-...
JUnit 5 - from Lambda to Alpha and beyond
1. from Lambda to Alpha and Beyond …
Sam Brannen
@sam_brannen
JUnit
2. 2
Sam Brannen
• Spring and Java Consultant @
• Java Developer for over 17 years
• Spring Framework Core Committer since 2007
• Swiss Spring User Group Lead
• Trainer & Conference Speaker
• JUnit 5 Core Committer since October 2015
3. 3
Swiftmind
Experts in Spring and Enterprise Java
Areas of expertise
• Spring *
• Java EE
• Software Architecture
• Software Development
Where you find us
• Zurich, Switzerland
• @swiftmind
• http://www.swiftmind.com
7. 7
Why a New Version of JUnit?
• JUnit 4.0 was released a decade ago
– a lot has changed since then…
– testing needs have matured
– expectations have grown
• Modularity big ball of mud
• Test discovery and execution tightly coupled
• Extensibility lot of room for improvement
• Let’s not forget Java 8
9. 9
JUnit 4 Runner API
• Very powerful
• In fact, it can do anything
• But… you can’t combine Runners
• Parameterized + SpringJUnit4ClassRunner no way
10. 10
JUnit 4… Rules… are meant to be broken
• JUnit 4.7: MethodRule (@Rule)
• JUnit 4.9: TestRule (@Rule / @ClassRule)
• Great for simple use cases
• Can even be combined
• But… a single rule can’t be used for method-level and
class-level callbacks
• Plus… zero support for instance-level callbacks
• Case in point: SpringClassRule / SpringMethodRule
12. 12
Crowdfunding Campaign
• Initiated by Johannes Link and
Marc Philipp
• Later joined by Matthias Merdes,
Stefan Bechtold, & Sam Brannen
• Ran from July to October 2015
• Raised 53,937 Euros from 474
individuals and companies
• 4 companies donated 6 weeks of
developer time
17. 17
JUnit 5… in a Nutshell
• Modular
• Extensible
• Modern
• Forward and backward compatible
– JUnit 5 supports JUnit 3.8 and JUnit 4
– Can be run with JUnit 4
• @RunWith(JUnit5.class)
18. 18
Architecture
• Test code depends only on
the JUnit 5 API.
• IDEs and build tools
depend on the Launcher
and Engine APIs and can
execute tests independent
of the testing framework
in use.
20. 20
Launcher API
• Used by IDEs and build tools to launch the framework
• Central API for discovering and executing tests via one or
more engines
• TestDiscoveryRequest
– selectors and filters
• Feedback provided via the TestExecutionListener API
21. 21
TestEngine API
• Test engine discovers and executes tests
– for a particular programming model
• Automatic discovery via Java’s ServiceLoader mechanism
• JUnit5TestEngine
• JUnit4TestEngine
• Implement your own…
25. 25
Assertions
org.junit.gen5.api.Assertions
• Limited set of core assertions
– assertEquals(), assertNotNull(), etc.
– plus assertThrows() and expectThrows()
– and assertAll()
• Supplier<String> for lazy failure message evaluation
– message is now the last parameter
• For more power, use AssertJ, Hamcrest, etc.
28. 28
Test Names
• Names default to test class or test method names
– characters limited based on Java syntax
• Custom display names @DisplayName
– Can contain spaces, special chars, and even emoji 😱
29. 29
Dependency Injection
• Extension Model meets Programming Model
• ParameterResolver extension
– resolves parameters for constructors or methods
• TestInfo: inject into constructor, @Test, @BeforeEach, etc.
– access display name, tags, class, method
• TestInfoParameterResolver
– eating our own dog food ;-)
• See also:
– TestReporter
– MockitoExtension
– SpringExtension
35. 35
Interface Default Methods
• Introduces the concept of a test interface
– Enables multiple inheritance in tests
– Kinda like testing traits
• @BeforeEach / @AfterEach
• @Test
• @Tag
• @ExtendWith
• See StringTests example in user guide
36. 36
Nested Test Classes
• Enables logical, hierarchical grouping of test classes
– with shared initialization and state from outer classes
• Declare @Nested on non-static nested classes
– i.e., inner classes
• You can even combine nested classes and test interfaces
• See TestingAStack example in user guide
37. 37
Spring Support for JUnit 5
• SpringExtension
– @ExtendWith(SpringExtension.class)
– https://github.com/sbrannen/spring-test-junit5
• Works with Spring Framework 4.3
• Already supports:
– Core Spring TestContext Framework features
– Constructor and method injection via @Autowired,
@Qualifier, @Value
• Fully integrated in Spring Framework 5.0