@storybook/jest compatibility

[jcamden]

Thank you so much, @bencompton, for this great package. It's been a tremendous help for us satisfying BDD requirements (feature files with scenarios we can sync to JIRA) while being able to stay as lightweight as possible with jest and @testing-library/react.

Lately, however, we're moving towards @storybook/react (with @storybook/interactions, @storybook/jest, and @storybook/testing library) especially in light of the automatic visual regression testing of stories with chromatic. As wonderful as we feel about that approach to frontend testing, it remains to be seen how we could integrate BDD. My first thought, of course, was to look into compatibility with jest-cucumber. I can't quite think of how it would work, unfortunately. The logic for steps would now be defined inside of the play methods of stories, rather than the .steps file we are used to running with jest and jest-cucumber.

Do you have any insights or tips (or interest) regarding compatibility between jest-cucumber and BDD? I sincerely appreciate your time!

[bencompton]

The short answer is that I don't feel that Gherkin is the best tool for the job regarding visual regression tests, or really anything outside of acceptance tests. Visual regression tests, unit tests, etc., don't really benefit from Gherkin, IMO. The purpose of Gherkin is to describe business rules and link them to automated tests. I always encourage my teams to eliminate all UI terminology from feature files because the focus should be on the rules, not the look and feel of the UI.

My philosophy is that other types of tests, like visual regression, can focus on the UI, and can use tools that are more appropriate for the job. IMO, the goal of feature files should be to concisely tell a story and provide key examples to demonstrate behavior, rather than being a dumping ground for every possible testing concern. That being said, using the same test runner (Jest) for acceptance tests and other types of tests is nice.

[jcamden]

Thanks for your response! I completely agree with you. And, thankfully, we would not be asked to connect Gherkin with anything to do with Storybook/Chromatic other than the behavioral tests we write with @storybook/interactions, @storybook/jest, and @storybook/testing library. (We would only incidentally get visual regression tests out of those behavioral tests, "for free," effort-wise.)

What we are thinking right now is something like this: with cucumber or jest-cucumber, there is always a gap between the purported behavior of a step definition and the code which actually implements that behavior. Ultimately, you still have to trust the developer that the step does what it says it does. We're using JIRA X-ray, God help us, and we're thinking maybe it's not too different to have some scenarios defined in JIRA linked to a story with interactions and assertions, and the gap that we have to trust here is that the story satisfies the "feature file" that is defined in the JIRA test ticket. In this case, we also have to trust that test tickets and stories have been kept in sync, which is probably not so great 🤔

Well! Maybe a solution will reveal itself. Thanks so much for your response!

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue is closed because there has been no recent activity.