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!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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!