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
I would strongly encourage the separation of functionality in the repo from the philosophical beliefs about writing tests in Gherkin. Primarily because for users who already have suites of Gherkin files, this repo becomes useless or another piece of work to extend to accommodate the gap. Basically, I think that omitting that major feature of Gherkin is more limiting to this project than the act of supporting an anti-pattern.
I would also like to suggest that tables are not always an anti-pattern. One of the main intentions of Cucumber is to provide a more human readable format. So, if the table is testing things like corner cases for inputs to a function, than the test is already going beyond what a non-technical user would comprehend.
However, tables are a great way to list what fields should be in a dropdown box or in a nav bar. They're also a great way to say what fields on a view are visible based on the user's permission. I do not really see how every table equates to the need for better unit testing.
The text was updated successfully, but these errors were encountered:
I would strongly encourage the separation of functionality in the repo from the philosophical beliefs about writing tests in Gherkin. Primarily because for users who already have suites of Gherkin files, this repo becomes useless or another piece of work to extend to accommodate the gap. Basically, I think that omitting that major feature of Gherkin is more limiting to this project than the act of supporting an anti-pattern.
I would also like to suggest that tables are not always an anti-pattern. One of the main intentions of Cucumber is to provide a more human readable format. So, if the table is testing things like corner cases for inputs to a function, than the test is already going beyond what a non-technical user would comprehend.
However, tables are a great way to list what fields should be in a dropdown box or in a nav bar. They're also a great way to say what fields on a view are visible based on the user's permission. I do not really see how every table equates to the need for better unit testing.
The text was updated successfully, but these errors were encountered: