-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
OLD Kickoff Agenda
Marc Philipp edited this page Feb 7, 2017
·
1 revision
- 09.30 - 09.45 Welcome
- 09.45 - 10.15 Introduction
- 10.15 - 10.30 Overview, History, Areas of Focus
- 10.30 - 11.00 Coffee Break
- 11.00 - 11.30 General topics (Johannes)
- 11.30 - 12.00 Programming model (Marc)
- 12.00 - 13.00 Lunch break
- 13.00 - 13.30 JUnit 5's extension model (Sam)
- 14.00 - 14.30 Coffee Break
- 14.30 - 15.15 Unconference-style group presentations/discussions
- 15.15 - 16.00 Unconference-style group presentations/discussions
- 16.00 - 16.30 Coffee Break
- 16.30 - 17.30 Wrap-up, plan day 2
- 09.00 Test API in IntelliJ IDEA (Anna)
- 10.00 Execution/Reporting API/SPI (Stefan, Matthias as backup)
- 11.00 Coffee break
- 11.30 Unconference-style group presentations/discussions
- 12.15 Wrap-up
- 12.30 Lunch break
- 13.30 Plan rest of the day
- 14.00
- 15.30 Coffee break
- 16.00 Wrap-up, plan day 3
- 17.00 Break
- 18.00 Dinner
TBD
- Prototype Execution/Reporting API/SPI and Programming/extension model in two groups
- Collect/share prototype ideas
- min. required Java version?
- third-party dependencies?
- modularization
- „add-on-modules“ (e.g. system-rules)
- what should be kept from JUnit 4?
- assertion library?
- communicate successful assertions?
- assumption library?
- skipping tests
- compatibility: using JUnit 3, 4, and 5 at the same time
- migration paths and migration tools?
- feature matrix comparing different JUnit versions
- Test definition
- Dynamic test registration (at runtime)
- Hierarchical structures/contexts
- Exception testing
- Lazy evaluation of failure messages
- Aggregated assertions
- Interaction with extensions
- Nested contexts
- Conditional test execution
- Ex:
@Category
,@Ignore
, assumptions -
TestSkippedException
vs.AssumptionViolatedException
- programmatic support:
-
assumeThat(...)
,assumeTrue(...)
assumingThat(condition).thenExecute(() -> {})
assumingThat(x).is(y).thenExecute(() -> {})
- Lifecycle callbacks (synchronous)
- bootstrap vs. test execution
- Method injection: Pluggable mechanism
- Communication between extensions
- Test discovery within a class
- Test execution
- Nested contexts
- Conditional test execution
- disabling/enabling of a test based on a condition
- Ex:
@Category
,@Ignore
, assumptions - pluggable expression parser (SPI) for evaluating conditions or generating names for parameterized test cases (e.g.
@Test(name="bla ${foo.bar}")
)? - Meta-annotations
- Test discovery on classpath/file system
- Sorting/ordering
- Filtering?
- Re-runnable, navigable test location source specification/description
- cross-process communication from IDEs and build tools using immutable data structures
- communication protocol should be explicit and part of the API
- report additional data and attach it to the test execution result (e.g. by returning a
Map
from test methods) - lifecycle events (asynchronous)
- stop/pause/restart the current execution
- Launch Parameters (configuration)
- parallel test execution
- pattern/selector for which tests to execute
- category of tests to execute
- Report generation
- consider introducing a standardized XML format
- food for thought: Generate JUnit XML report from JUnitCore