Thanks for the article. I am not a fan of the UI-centric phrasing you chose for your example because I think it conflates business logic and UX flow. BDD tests have a reputation for being end-to-end tests but it doesn't have to be the way.
IMO the problem with end-to-end testing everything is they end up tracing over the same steps many times, e.g. every test might be logging in, and UI testing is already slow and inherently brittle even when used sparingly.
For testing the business logic perhaps the test could be phrased as:
Given user "bob" exists with a public repository "cool project"
When I search for user "bob"
Then I retrieve his repositories
This could be implemented as a set of API calls, and multiple tests could be written to exercise various happy and sad paths relating to e.g. permissions without ending up being overly slow.
For testing the UX I would think along the lines of:
Given I am on the main page
When I search for a user that exists
Then I should get that user's repositories
This test will work on any client (web, app, voice, terminal?), and could be implemented without touching business logic. E.g. the implementation could be a set of views tied around a hard coded model feeding canned data.
Just some thoughts. Keep up the blogging!
Hello Jon, Thank you for sharing your thoughts. Let me share mine.
I agree that I was preoccupied with my test example, as while I was writing the article I was thinking of explicit steps on how to test a particular scenario. For example, you need to focus on the input search box and start typing and then you need to press enter to send. However, this is just an example workflow. You could have implemented your UI code to only send by clicking a button or pressing a specific key. Or you could have 10 different scenarios on how to search. All could be different options.
The idea behind it is that for every step you need to implement the test cases in code so it's important to use wording that you can subsequently test. If you put too many generic steps you leave too much to be interpreted impromptu. Of course, you could have phrased a different way to test variations of scenarios. It's up to each project requirements.
I agree BDD can be used to do unit tests also. It just you have to use a smaller scope to actually describe your scenarios.
I believe when you refer to business logic in your example you mean the integration and the systems test cases, where you test a group of modules for example both the UI and both the backend for a particular feature; in that case, we care that the search works for existing users by testing the system as a whole.
How you test that is important... Of course, this article is not about how to write those tests cases or how to write good tests in general as this is another big story.
Thank you again and I'm waiting to read your own posts!
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.