Interesting post thanks for this. I've naturally been more drawn to bdd but I always find there is a wealth of information for TDD along with testing frameworks to support with little information associated with the bdd counterpart.
That's because TDD is just an approach that can be implemented with almost all the existing test frameworks that the developers use.
While the software developer is more familiar with the application layer and Software Arquitecture in the business layer the stakeholders are the experts, they are normally Business Analysts and are familiarized with the Enterprise Architecture.
They might think that the automated tests is something out of their scope. At most they try to do manual tests, because programming tests in one of the existing frameworks requires knowledge of ... programming.
Have you heard about the impedance that exist between developers and stakeholders ? E.g.: between the programmers and the the future users of the systems ?
That impedance is given by the fact that one has lower expertise in the domain of the other. The developer normally knows about technologies that can be applied in many domains. The users are expert of the domain, but they usually don't know the details of how technology works, or the whole spectrum of advantages that it can provide. (check the book Object Oriented Analysis and Design with Applications from Grady Booch for more on this)
The same existence of the new software changes this correlation. Even from its prototype phase. The developer knows more about the problem domain and the users starts to realize of how much advantage the technology provide to their business.
Normally the stakeholder represents the communication channel between both. They negotiate the requirements with both parts and estimate the costs. They are normally experts to some limited degree of both fields. Usually both parts depend on them for the success of the project, and this provides big part of the economic benefits.
I think BDD provides more benefit here to the stakeholder, they can realize immediately when the implementation of one scenario conflicts with the implementation of the other. The sooner this is detected is better in order to optimize the use of the resources.
For everybody is better that the functional requirements are cleared stated sooner, but the stakeholder has most of the benefits because they have a possible artifact to validate their work...
... but they don't know normally how to program the tests. That's why you see the BDD tests less popular.
And also, because programmers are usually lazy to map all the concepts of the business notations to the BDD test language.
Programmers are also lazy to write scenarios for everything.
Actually, many developers I know prefer to write their unit tests as thin as possible (instead of seeding the db with data per scenario to cover all aspects in the scenario).
I believe their approach sucks eventually since they still cover things from the tech perspective more than the business side.
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.
Interesting post thanks for this. I've naturally been more drawn to bdd but I always find there is a wealth of information for TDD along with testing frameworks to support with little information associated with the bdd counterpart.
I agree with you.
TDD is so popular that every framework vendor tries to provide tooling to do it... though TDD might not be a good option for your project 🙄
That's because TDD is just an approach that can be implemented with almost all the existing test frameworks that the developers use.
While the software developer is more familiar with the application layer and Software Arquitecture in the business layer the stakeholders are the experts, they are normally Business Analysts and are familiarized with the Enterprise Architecture.
They might think that the automated tests is something out of their scope. At most they try to do manual tests, because programming tests in one of the existing frameworks requires knowledge of ... programming.
Have you heard about the impedance that exist between developers and stakeholders ? E.g.: between the programmers and the the future users of the systems ?
That impedance is given by the fact that one has lower expertise in the domain of the other. The developer normally knows about technologies that can be applied in many domains. The users are expert of the domain, but they usually don't know the details of how technology works, or the whole spectrum of advantages that it can provide. (check the book Object Oriented Analysis and Design with Applications from Grady Booch for more on this)
The same existence of the new software changes this correlation. Even from its prototype phase. The developer knows more about the problem domain and the users starts to realize of how much advantage the technology provide to their business.
Normally the stakeholder represents the communication channel between both. They negotiate the requirements with both parts and estimate the costs. They are normally experts to some limited degree of both fields. Usually both parts depend on them for the success of the project, and this provides big part of the economic benefits.
I think BDD provides more benefit here to the stakeholder, they can realize immediately when the implementation of one scenario conflicts with the implementation of the other. The sooner this is detected is better in order to optimize the use of the resources.
For everybody is better that the functional requirements are cleared stated sooner, but the stakeholder has most of the benefits because they have a possible artifact to validate their work...
... but they don't know normally how to program the tests. That's why you see the BDD tests less popular.
And also, because programmers are usually lazy to map all the concepts of the business notations to the BDD test language.
Programmers are also lazy to write scenarios for everything.
Actually, many developers I know prefer to write their unit tests as thin as possible (instead of seeding the db with data per scenario to cover all aspects in the scenario).
I believe their approach sucks eventually since they still cover things from the tech perspective more than the business side.