Tag Archives: junit5

automated testing for digital experiences using junit 5 – live blogging from spring days

Posted on by
Reply

Automated Testing for Digital Experiences Using JUnit 5
Speaker: Justin Baumgartner
See list of all blog posts from conference

General

  • Asked how many use JUnit 4. Almost everyone. [didn’t ask about TestNG, but did cite most used framework in general]
  • JUnit 4 is ten years old
  • “It’s all about the tests” – TDD/CI/CD – create. more importance on tests

Gaps in JUnit 4

  • Tight coupling between the APIs we use to write tests and the ones build tools use. Separating the jars lets progress at different speeds
  • Built on Java 5. Can’t use lambdas [aside from a tiny bit in assertj]
  • Runner restrictions – can only have one
  • Rules aren’t flexible enough

JUnit 5

  • Release in early fall
  • New architecture: JUnit platform (for build tools and IDEs to discover and execute tests), JUnit Jupiter (for writing tests), JUnit Vintage (to run legacy tests)
  • Potential for Cucumber or Spock runner so can run all tests in one place
  • Extension model: Can hook into life cycle callbacks. Used instead of runners/rules. An extension point is an interface. Example BeforeEachCallback. Need to be stateless; get TestExtensionContext as parameter. Can implement multiple callback if want called multiple times and store state in getStore(context).
  • Can pass parameters into test methods using @ExtendWith(xxx.class) so narrow scope. Implement ParameterResolver to create the object you want to mock.
  • Dynamic tests: create tests at runtime. Not expected to use often. @TestFactory and then create tests as lambdas. Each dynamicTest in list is an actual test (vs run in a loop
  • @ParmeterizedTest and @ValueSources – hard code parameters, read from file. [need to look at how to run “legacy” style parameterized test – answer – there’s. a @MethodSource where you can havve any logic]
  • RepeatedTest(x) – to run test a bunch of times
  • @Disabled – can disable class or test. Appear in report but not run. (unlike @Ignore where don’t appear in report at all)
  • @DisplayName so can print clearer name than test name
  • @Tag – replaces @Category – to grou/filter tests
  • assertAll() – new assertion – facilitates grouping of assertions

Said backward compatible. But not all runners/rules are in Jupiter. So would have to use Vintage test engine to use those or port. Jupiter has different packages for annotations/assertions so can mix within class. So if using Jupiter engine, still can use “old” asserts until change imports.

Nice ending presentation. I’m really excited about JUnit 5!