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
Copy file name to clipboardExpand all lines: docs/release_notes.adoc
+40Lines changed: 40 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -37,6 +37,25 @@ _This is a summary of the highlights of the milestone releases_
37
37
38
38
=== Breaking Changes
39
39
40
+
* It is no longer true that only top-level expression statements are treated as implicit conditions.
41
+
Just like within `with { ... }`, `verifyAll { ... }`, `@ConditionBlock` methods, and other places,
42
+
each expression statement is now considered an implicit condition, except for statements in unknown
43
+
closures.
44
+
+
45
+
This enables the usage of `if` and similar while also being able to still safely use `.every { ... }`,
46
+
but without the regular confusion why a test is not failing if the condition is inside an `if`.
47
+
You can even have interactions in those nested places now.
48
+
+
49
+
As now expression statements are considered implicit conditions that previously were not,
50
+
this can lead to compilation errors in existing code-bases, because such nested statements were
51
+
previously simply ignored by the Spock compiler and now also must be valid conditions.
52
+
+
53
+
If those compile errors are not accidentally written assignments that should have been conditions
54
+
or similar, you can for example use the <<spock_primer.adoc#opt-out-of-condition-handling,`!!` prefix operator>>
55
+
to declare an expression statement explicitly as not being an implicit condition.
56
+
+
57
+
spockPull:2250[]
58
+
40
59
* _This affects users of the `@Snapshot` extension, only if you were using the snapshotter in parent specification classes._ +
41
60
`@Snapshot` used to look up snapshots in directories named after the class containing feature methods. Now, the snapshots will be loaded from directories named after the bottom class in the specification hierarchy. The motivation of the change is to allow users to define features in base specification classes, but overwrite expected snapshots per child specification.
42
61
spockPull:2112[]
@@ -69,6 +88,27 @@ will now require that the spec is annotated with <<parallel_execution.adoc#isola
69
88
* Spock supports Groovy 5.0 spockIssue:2196[]
70
89
* Spock is also tested to run correctly on Java 25 LTS spockPull:2212[]
71
90
91
+
=== Breaking Changes
92
+
93
+
* It is no longer true that only top-level expression statements are treated as implicit conditions.
94
+
Just like within `with { ... }`, `verifyAll { ... }`, `@ConditionBlock` methods, and other places,
95
+
each expression statement is now considered an implicit condition, except for statements in unknown
96
+
closures.
97
+
+
98
+
This enables the usage of `if` and similar while also being able to still safely use `.every { ... }`,
99
+
but without the regular confusion why a test is not failing if the condition is inside an `if`.
100
+
You can even have interactions in those nested places now.
101
+
+
102
+
As now expression statements are considered implicit conditions that previously were not,
103
+
this can lead to compilation errors in existing code-bases, because such nested statements were
104
+
previously simply ignored by the Spock compiler and now also must be valid conditions.
105
+
+
106
+
If those compile errors are not accidentally written assignments that should have been conditions
107
+
or similar, you can for example use the <<spock_primer.adoc#opt-out-of-condition-handling,`!!` prefix operator>>
108
+
to declare an expression statement explicitly as not being an implicit condition.
109
+
+
110
+
spockPull:2250[]
111
+
72
112
=== Misc
73
113
74
114
* Fix handling of condition method calls spockPull:2162[]
0 commit comments