TDD : If developers write the tests first, and implement the feature later.
BDD : If developers write the tests first (specified in a language that describes the behaviour of the system as a whole) and implement the feature later.
Something curious is that when I started to use this kind of tests, some years ago, it had the same acronym but a wider concept. It was named Business driven development.
Ohh those were times where software development were more like a Science that an Art ! :-D
The software engineering, the architecture patterns, the methods and practice had a leading role. The object oriented paradigm was designed to divide the complexity inherent of software and make its components flow through the software teams. It was specially useful to develop software of industrial strength whose complexity was specified by requirements of the problem domain (how the business work).
But with the boom of the cloud, social networks, and software as a service did appear a myriad of new possibilities to drive the other complexity with lower costs. That is the one defined by non-functional requirements (storage, location, concurrent execution, data availability). Big companies did provide frameworks and services for them and millennial developers could done more with less.
From my point of view, the software development companies like to be more Agile to lower costs. And that means for many "do it as you can, but fast". Many team leaders are programmers with a big knowledge of the trending frameworks and without a deep understanding software architecture. Methodology is an scary word for many investors that want the software to be done fast and have less respect by the way the software is internally organized.
From old times we inherit the name business scenario. That time where BDD did mean Business Driven Development. Nowadays they name used is Behaviour Driven Development and the focus remain in the software system.
The problem is that the scope is more restricted. Let us say that the term Behaviour Driven Scenario is related to Business Driven Scenario in the same proportion that Software Arquitecture is related to Enterprise Arquitecture.
The software is just a part of the big system that is the enterprise. The software architecture just cover the Applications layer of the following diagram:
...while the Enterprise Architecture covers also the Business Layer, the Technology Layer, etc.
As the Pyramid implies, the changes at the upper layers imply changes of bigger complexity at lower layers.
The concepts at every layer have corresponding concepts at the lower layers. And my opinion is that the corner stone of all is the Business Scenario.
The Business Scenario is defined by the methodologies of Enterprise Architecture like TOGAF.
My opinion is that the Agile people have tried reduced the scope of BDD concept, but there will come a time where the scope will be widened again.
In general, I would say that:
BDD is related to TDD the same way as the Business is to the Software. A wider concept.
What you provide is a test system that describe, in a simple language that the stakeholder can understand, the main source of changes in the application.
So it is a very important contribution. Congratulations!
I would better say: How BDD relates to TDD?. Normally vs is used to denote a comparison where both term are opposed and you should choose one.
The problem is that BDD is a kind of TDD. One simple definition is:
TDD : If developers write the tests first, and implement the feature later.
BDD : If developers write the tests first (specified in a language that describes the behaviour of the system as a whole) and implement the feature later.
Something curious is that when I started to use this kind of tests, some years ago, it had the same acronym but a wider concept. It was named Business driven development.
Ohh those were times where software development were more like a Science that an Art ! :-D
The software engineering, the architecture patterns, the methods and practice had a leading role. The object oriented paradigm was designed to divide the complexity inherent of software and make its components flow through the software teams. It was specially useful to develop software of industrial strength whose complexity was specified by requirements of the problem domain (how the business work).
But with the boom of the cloud, social networks, and software as a service did appear a myriad of new possibilities to drive the other complexity with lower costs. That is the one defined by non-functional requirements (storage, location, concurrent execution, data availability). Big companies did provide frameworks and services for them and millennial developers could done more with less.
From my point of view, the software development companies like to be more Agile to lower costs. And that means for many "do it as you can, but fast". Many team leaders are programmers with a big knowledge of the trending frameworks and without a deep understanding software architecture. Methodology is an scary word for many investors that want the software to be done fast and have less respect by the way the software is internally organized.
From old times we inherit the name business scenario. That time where BDD did mean Business Driven Development. Nowadays they name used is Behaviour Driven Development and the focus remain in the software system.
The problem is that the scope is more restricted. Let us say that the term Behaviour Driven Scenario is related to Business Driven Scenario in the same proportion that Software Arquitecture is related to Enterprise Arquitecture.
The software is just a part of the big system that is the enterprise. The software architecture just cover the Applications layer of the following diagram:
...while the Enterprise Architecture covers also the Business Layer, the Technology Layer, etc.
As the Pyramid implies, the changes at the upper layers imply changes of bigger complexity at lower layers.
The concepts at every layer have corresponding concepts at the lower layers. And my opinion is that the corner stone of all is the Business Scenario.
The Business Scenario is defined by the methodologies of Enterprise Architecture like TOGAF.
My opinion is that the Agile people have tried reduced the scope of BDD concept, but there will come a time where the scope will be widened again.
In general, I would say that:
What you provide is a test system that describe, in a simple language that the stakeholder can understand, the main source of changes in the application.
So it is a very important contribution. Congratulations!
Thanks for the input, I really see things much clearer now.
And, I always felt that BDD is just a kind of TDD done such that:
This says it all !