I have found it extremely useful during software maintenance and evolution. I put an example:
I had to improve one part of one complex report engine, in order to support some formatting. The component I did need to improve had interactions with not so many different components, just with the one who use it. The problem is that there were too many possible inputs and I could not analyze the whole engine to understand who it works.
They had a big set of business tests, that tested the possible workflows of the whole system using BDD tests. Hundreds of reports were tested for every known use case (crm, purchase, sales, inventory, production, etc..)
What I have done is to run the complete set of tests with a modified version of the original component that did save the method calls and the responses.
Then I had hundred of unit tests for my new component, that I did run on every change. I did safe even resources and time, because now I didn't have to run the whole system in order to test my component.
After few days my replacement component was ready, with all the known cases covered, and the new ones required.
The replacement was successful, IMHO.
And I did save time to know how the whole report engine work.
That did demonstrate me the useful the workflow (bdd) tests were to generate unit test contexts.
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.
I have found it extremely useful during software maintenance and evolution. I put an example:
I had to improve one part of one complex report engine, in order to support some formatting. The component I did need to improve had interactions with not so many different components, just with the one who use it. The problem is that there were too many possible inputs and I could not analyze the whole engine to understand who it works.
They had a big set of business tests, that tested the possible workflows of the whole system using BDD tests. Hundreds of reports were tested for every known use case (crm, purchase, sales, inventory, production, etc..)
What I have done is to run the complete set of tests with a modified version of the original component that did save the method calls and the responses.
Then I had hundred of unit tests for my new component, that I did run on every change. I did safe even resources and time, because now I didn't have to run the whole system in order to test my component.
After few days my replacement component was ready, with all the known cases covered, and the new ones required.
The replacement was successful, IMHO.
And I did save time to know how the whole report engine work.
That did demonstrate me the useful the workflow (bdd) tests were to generate unit test contexts.