Report is rendered incorrectly when table in table is required

[nikowitt]

Hi Jan,

I've discovered another in a more complex report:

    private static QuestionNumberHolder $N(String oldNumber, String newNumber) {
        return new QuestionNumberHolder(oldNumber, newNumber);
    }

    @DataProvider
    public static Object[][] dataset_refresh_numbering() {
        return $$(
                $("4", null, $N("4", "5"), $N("5", "6"), $N("6", "7")),
                $("2.1", "2", $N("2.1", "2.2"), $N("2.2", "2.3")),
                $("2", null, $N("2.1", "3.1"), $N("2.1.2", "3.1.2")));
    }

    @Test
    @UseDataProvider("dataset_refresh_numbering")
    public void refresh_numbering(String nextPosition, String parent, QuestionNumberHolder... holders) throws Exception {
        given().logged_in_system_user();
        when().question_$_is_created_before_question_$_with_parent_$("TEST", nextPosition, parent).and().numbering_is_refreshed();
        then().numbering_matches(holders);
    }

where the QuestionNumberHolder is

public class QuestionNumberHolder {

    private final String oldNumber;
    private final String newNumber;

    public QuestionNumberHolder(String oldNumber, String newNumber) {
        this.oldNumber = oldNumber;
        this.newNumber = newNumber;
    }

    public String getOldNumber() {
        return oldNumber;
    }

    public String getNewNumber() {
        return newNumber;
    }

}

and

public ThenStep numbering_matches(QuestionNumberHolder... holders) throws Exception {
...
}

creates the following report:

 Scenario: refresh numbering

   Given logged in system user
    When question "TEST" is created before question <nextPosition> with parent <parent>
     And numbering is refreshed
    Then numbering matches <holders>

  Cases:

    | # | nextPosition | parent | holders                                                                                                                                                                                                                                                 | Status  |
    +---+--------------+--------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------+
    | 1 |            4 | null   | com.sobis.suma.businessobject.questionnaire.helpers.QuestionNumberHolder@2e222612, com.sobis.suma.businessobject.questionnaire.helpers.QuestionNumberHolder@61386958, com.sobis.suma.businessobject.questionnaire.helpers.QuestionNumberHolder@73ee04c8 | Success |
    | 2 |          2.1 | 2      | com.sobis.suma.businessobject.questionnaire.helpers.QuestionNumberHolder@7671cb68, com.sobis.suma.businessobject.questionnaire.helpers.QuestionNumberHolder@49dc7102                                                                                    | Success |
    | 3 |            2 | null   | com.sobis.suma.businessobject.questionnaire.helpers.QuestionNumberHolder@6b8ca3c8, com.sobis.suma.businessobject.questionnaire.helpers.QuestionNumberHolder@68c72235                                                                                    | Success |

It now makes sense to add @table:

public ThenStep numbering_matches(@Table QuestionNumberHolder... holders) throws Exception {
...
}

but this results in

Test Class: com.sobis.suma.tests.managers.QuestionManagerTest

 Scenario: refresh numbering

   Given logged in system user
    When question "TEST" is created before question <nextPosition> with parent <parent>
     And numbering is refreshed
    Then numbering matches

     | oldNumber | newNumber |
     +-----------+-----------+
     |         4 |         5 |
     |         5 |         6 |
     |         6 |         7 |


  Cases:

    | # | nextPosition | parent | holders                                                                                                                                                                                                                                                 | Status  |
    +---+--------------+--------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------+
    | 1 |            4 | null   | com.sobis.suma.businessobject.questionnaire.helpers.QuestionNumberHolder@2e222612, com.sobis.suma.businessobject.questionnaire.helpers.QuestionNumberHolder@61386958, com.sobis.suma.businessobject.questionnaire.helpers.QuestionNumberHolder@73ee04c8 | Success |
    | 2 |          2.1 | 2      | com.sobis.suma.businessobject.questionnaire.helpers.QuestionNumberHolder@7671cb68, com.sobis.suma.businessobject.questionnaire.helpers.QuestionNumberHolder@49dc7102                                                                                    | Success |
    | 3 |            2 | null   | com.sobis.suma.businessobject.questionnaire.helpers.QuestionNumberHolder@6b8ca3c8, com.sobis.suma.businessobject.questionnaire.helpers.QuestionNumberHolder@68c72235                                                                                    | Success |

Actually, a nested table is expected, but instead the first entry in the dataset is used in the scenario description and the cases don't change, so this is basically some mixup.

Maybe this is interesting for you. My current workaround is to override QuestionNumberHolder's toString().

[janschaefer]

I am not sure what a good fix would be. Because nesting a table in a table will become ugly, I guess. I think the best solution would be to not generate a data-table and print all cases separately.

There is a related issue: #86.

[nikowitt]

Ah, sorry, for posting a duplicate.
Some small improvement is already to be able to control the separator for which currently, a comma is used. By e.g. being able to use \t, the readability + overriden the toString() could already help a but.