Incorrect aggregation of conditions in report using @NestedSteps

[nikowitt]

Hi Jan,

some thing I've just discovered:

@RunWith(ApplicationJUnit4ClassRunner.class)
@SpringTestContext
public class SuperBoxControllerTest extends JAFSimpleScenarioTest<SuperBoxStage> {

	@DataProvider
	public static Object[][] querySuperbox() {
		return $$(
				//@formatter:off
				$("62: internal users with mail address", SuperBoxQueryTypes.INTERNAL_USERS_WITH_EMAIL_ONLY, null, $M(false, SampleUser.INTERNAL_AUTHOR_PROJECT_1.getUserName()), SampleUser.SYSTEM.getUserName()),
				$("62: typeahead for internal author", SuperBoxQueryTypes.INTERNAL_USERS_WITH_EMAIL_ONLY, SampleUser.INTERNAL_AUTHOR_PROJECT_1.getUserName(), $M(true, SampleUser.INTERNAL_AUTHOR_PROJECT_1.getUserName()), SampleUser.SYSTEM.getUserName())
				//@formatter:on
		);

	}

	@Test
	@UseDataProvider
	@CaseDescription("$0")
	public void querySuperbox(String description, SuperBoxQueryTypes type, String query, SuperboxMatch results, String excludeFromResult) {
		given().logged_in_user_is(SampleUser.SYSTEM.getUserName());
		when().superbox_query_type_$_with_query_$_is_prepared(SuperBoxController.class, type, query).and().request_is_executed();
		then().expected_matches_are_verified(results);
		if (!JAFStringUtils.isEmpty(excludeFromResult)) {
			then().and().json_result_$_value(false, excludeFromResult);
		}

	}

	static class SuperBoxStage extends SuperBoxStage<SuperBoxStage> {

		@NestedSteps
		public SuperBoxStage expected_matches_are_verified(@Hidden SuperboxMatch results) {

			if (results != null) {
				if (results.isStrictMatch()) {
					json_entries_$_total_matches_are_found(results.getMatches().length);
				} else {
					json_entries_$_found(true);
				}
				for (String match : results.getMatches()) {
					json_result_$_value(true, match);
				}
			} else {
				json_entries_$_found(false);
			}

			return self();
		}

	}

	public static class SuperboxMatch {

		private final boolean strictMatch;
		private final String[] matches;

		private SuperboxMatch(boolean strictMatch, String... matches) {
			this.strictMatch = strictMatch;
			this.matches = matches;
		}

		public boolean isStrictMatch() {
			return strictMatch;
		}

		public String[] getMatches() {
			return matches.clone();
		}

		public static SuperboxMatch $M(boolean strictMatch, String... matches) {
			return new SuperboxMatch(strictMatch, matches);
		}
	}
}

In the dataprovider, two matches ($M(...)) are instantiated, one with strict match checking ($M(true,...), another without strict match checking ($M(false,...). In expected_matches_are_verified, two different paths are selected for strict match checking.
So when I run the test, I expect two reports to be rendered without a table aggregation:

 Query superbox

   Given logged in user is "system"
    When superbox query type "internal users with email only" (21) with query <not set> is prepared
     And request is executed
    Then expected matches are verified
           json entries are found
           json result contains value "author1@sobis.com"
     And json result does not contain value "system"

and

 Query superbox

   Given logged in user is "system"
    When superbox query type "internal users with email only" (21) with query "author1@sobis.com" is prepared
     And request is executed
    Then expected matches are verified
           1 total matches are found
           json result contains value "author1@sobis.com"
     And json result does not contain value "system"

But instead, the cases are summarized:

 Query superbox

   Given logged in user is "system"
    When superbox query type "internal users with email only" (21) with query <query> is prepared
     And request is executed
    Then expected matches are verified
           json entries are found
           json result contains value "author1@sobis.com"
     And json result does not contain value "system"

  Cases:

   | # | Description                           | query               | Status  |
   +---+-----------------------------------------+------------------+---------+
   | 1 | 62: internal users with mail address | <not set>           | Success |
   | 2 | 62: typeahead for internal author    | "author1@sobis.com" | Success |

So the strict match condition check is not considered. Is the analyzer smart enough to detect such a deep condition?

[janschaefer]

I have not looked into the code yet, but it looks like nested steps are not considered yet.

[janschaefer]

This issue is actually quite interesting, because I think I have never thought about nested steps with parameters in general :-)

[nikowitt]

Works fine with jgiven-core-0.12.2-20161101.222126-16.jar, thank you! (So you should assign the proper JGiven version to this issue :)):

 Query superbox

  Case 1: 62: internal users with mail address

   Given logged in user is "system"
    When superbox query type "internal users with email only" (21) with query <not set> is prepared
     And request is executed
    Then expected matches are verified
           json entries are found
           json result contains value "author1@sobis.com"
     And json result does not contain value "system"

  Case 2: 62: typeahead for internal author

   Given logged in user is "system"
    When superbox query type "internal users with email only" (21) with query "author1@sobis.com" is prepared
     And request is executed
    Then expected matches are verified
           1 total matches are found
           json result contains value "author1@sobis.com"
     And json result does not contain value "system"

[janschaefer]

Great, thanks for testing the snapshot version! And yes, I have to update the version :-). There will never be a 0.12.2 version.