[test-stack] Implement inner class assertion and fix typo "doesNotContains"#18921
Conversation
7a251fa to
7e551c9
Compare
|
@wing328 Kindly take a gander. Please merge before #18917 as it builds on the features that are introduced here. Doing separate PRs as i want to start more clearly separating scope / concerns here, makes things easier in case anything comes up and a revert should be needed. I was temped to press the merge button myself as i'm confident this PR is a non-critical feature addition to the test stack … however i don't want to take liberties here… |
7e551c9 to
965a512
Compare
|
can you please resolve the merge conflicts when you've time? after that i'll get it merged. |
965a512 to
964e070
Compare
So .hasAssertion(String) can replace .assertMethodAnnotations().containsWithName(String)
This makes our the assertion API more consistent, in the way that
assertSomething("") will always return a different assertion type,
while hasSomething("") will always return the same type.
410666a to
6af0eae
Compare
Done! Actually that merge conflict was a stroke of luck b/c i realized the API i introduced did not have the consistency i intended when i tried to apply the added As part of that, i also harmonized the inconsistency between Updated the PR description and rebased #18917 on this, so that should go through easily. |
After some hours of wrestling Generics, this finally works as intended and mainly adds the following:
JavaFileAsserthasAnnotation(String)anddoesNotHaveAnnotation(String)toMethodAssertand the newInnerClassAssert(these can be used to avoid writing.assertMethodAnnotations().containsWithName(String)and.assertMethodAnnotations().doesNotContainWithName(String), respectively.Also did changes to harmonize and improve our JavaFileAssert API:
…doesNotContains…(that has been triggering my inner Monk for many time 😄 )ListAssertare now pluralized (i.e.MethodAnnotationsAssertinstead ofMethodAnnotationAssert) to make it easier to understand whether you are asserting on a collection or an actual elementassertSomething(…)now always returns a new assertion object (going one level deeper), whilehasSomething(…)returns the same object (staying on the same level)In general, there is more about this API that should be harmonized, but for starters i'm happy.
PR checklist
Commit all changed files.
This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
These must match the expectations made by your contribution.
You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example
./bin/generate-samples.sh bin/configs/java*.IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
master(upcoming 7.6.0 minor release - breaking changes with fallbacks),8.0.x(breaking changes without fallbacks)