Large specifications can break Behat test generation

[TravisCarden]

A large enough data set can break the Behat test generation due to character length limits in Google Sheets. ("Text result of JOIN is longer than the limit of 50000 characters.") This could be fixed by refactoring the test generation--perhaps by writing a custom function. It could also be sidestepped by using CSV files instead of Gherkin data tables.

[brianreese]

Hi @TravisCarden
I ran into this issue and took a stab a resolving it with a custom function. It looks like a string returned from a custom function is still limited to 50000 characters. However, the function can return an array which would be expanded across multiple rows. I'm currently doing this on a separate sheet.

To make it easier to copy and paste, I'm then using the QUERY function to combine rows from the additional sheet. I found a workaround using an ARRAYFORMULA and the QUERY's header clause to allow more than 50000 characters into a single cell.

The changes I made to my sheet look like this:

• Added custom function to generate the content model feature
• Added a new (hidden) sheet, which calls the custom function in A1
• Replaced the formula for the Content model feature on the existing Behat sheet with a new formula leveraging the above work around

See this gist for the code used:
https://gist.github.com/darkcody/30c8a197e596b1e9dee6d390639cf934

[greggmarshall]

What about as a first approximation splitting the bundles and fields into two separate feature files? That will buy some additional capacity.

[TravisCarden]

@greggmarshall I would be open to a change like that if it could be argued to be the best from a usability or developer experience standpoint. But I wouldn't want to change the way things work and break backward compatibility in any way. I would prefer to take the approach of creating a custom function for it... but I would need someone to help with that as I have no time allocated to this project at present.

[greggmarshall]

Travis

I don't think a custom function will solve the problem after reading @brianreese's comment above, it still has the same 50,000 character limitation the current implementation is running into.

If we split the bundles and fields into two separate feature files, or at least two cells on the behat tab of the spreadsheet, you buy a little (not much additional capacity), but more importantly you leave open the possibility of taking the fields and generating the scenario another way. If you don't want to break compatibility with the existing context files, add instructions to that tab to combine the outputs into a single feature file.

One option for generating large fields scenarios might be creating a fields scenario tab that operates somewhat like the fields csv tab putting one row of the fields tab on each row of the scenario which could be exported to a text file. Another option might be extend nickwilde1990/drupal-spec-tool-commands to generate the scenario directly by pulling the fields tab and building the scenario while populating the corresponding feature file.

[greggmarshall]

Here's my Rube Goldberg solution that seems to work (at least I think so)

I changed the hidden cell B8 in the Behat tab to only have the Scenario text

 ="  Scenario: Fields
     Then exactly the following fields should exist
 "

And I added some additional instructions to append Column A of a new tab I added called Behat Fields. In that tab I added the formula which is adapted from what I removed in B8 but puts one field per row in the A column.

 =ARRAYFORMULA(
        FILTER(
         "      | " & 'Fields CSV'!A:A & " | " & 'Fields CSV'!B:B & " | " & 'Fields CSV'!C:C & " | " & 'Fields CSV'!D:D & " | " & 'Fields CSV'!E:E & " | " & 'Fields CSV'!F:F & " | " & 'Fields CSV'!G:G & " | " & 'Fields CSV'!H:H & " | " & 'Fields CSV'!I:I & " |",
         NOT(ISBLANK('Fields CSV'!A:A))
       )
     )

I ended up with some extra blank lines at the end which I manually deleted although I don't think they affect the tests.

[tgifford-webfirst]

Another option might be extend nickwilde1990/drupal-spec-tool-commands to generate the scenario directly by pulling the fields tab and building the scenario while populating the corresponding feature file.

This is exactly what I was thinking as well. I may be able to get some time to do this, but I'm starting out with the row-per-field solution from @greggmarshall for now.

[TravisCarden]

@NickDickinsonWilde do you have any input on this issue considering the impact any changes might have on https://github.com/NickDickinsonWilde/drupal-spec-tool-commands?

[tgifford-webfirst]

I implemented a workaround PR in drupal-spec-tool-commands that relies on placeholders to pull in data from other tabs.