BDD tests the complete behavior of a system. You can refractor the system a hundred different ways and completely change implementation if you like (or even start using a completely different programming language) and as long as the BDD tests continue to pass, you know you have NOT changed the features and behavior of your system. You know, 100%, that you have not broken the system as a whole.
With regard to 1 and 2:
1) Every product owner is different. Some do like to write down what they want. Some don't. In no way does this give a developer the excuse of not developing to specifications/features/behavior. Part of that "technical" stuff that you are paid for is to assure that you have actually developed the exact behavior what was asked for. Nothing more. Nothing less. At the very least, you have something that a BA/PO/Manager/Client can look at when they say let you know you gave them something they didn't want.
2) If hey don't have time to define the behavior of your system (or delegate that task) then you really don't have time to understand their customer nor find that set of features that gives them the best ROI.
To my understanding, we need both. As in, we need TDD for unit-level, and BDD/Acceptance Test (like Fit/FitNesse) for high-level.
Is this correct?
Pardon me if I'm not really high into these various testing technique other than TDD because
1) It's damn hard to make people even start writing Unit-tests let alone doing TDD
2) It's damn hard to make people do TDD
3) It's even harder to argue that some people are actually writing unit-tests as opposed to integration-tests (especially for those who uses NoSQL database)
4) We're not even at the point where we knew how to write good unit-tests (yes, we know some rule, for example, not touching the database, and so on, but I bet there are other better ways unexplored in regard to writing good unit-tests)
So with that in mind, I'll focus on one problem at a time. Once I feel that TDD is at the "proven level", then perhaps I'll check BDD.
With regard to BDD not being a big loss:
BDD tests the complete behavior of a system. You can refractor the system a hundred different ways and completely change implementation if you like (or even start using a completely different programming language) and as long as the BDD tests continue to pass, you know you have NOT changed the features and behavior of your system. You know, 100%, that you have not broken the system as a whole.
With regard to 1 and 2:
1) Every product owner is different. Some do like to write down what they want. Some don't. In no way does this give a developer the excuse of not developing to specifications/features/behavior. Part of that "technical" stuff that you are paid for is to assure that you have actually developed the exact behavior what was asked for. Nothing more. Nothing less. At the very least, you have something that a BA/PO/Manager/Client can look at when they say let you know you gave them something they didn't want. 2) If hey don't have time to define the behavior of your system (or delegate that task) then you really don't have time to understand their customer nor find that set of features that gives them the best ROI.