3 ms·

BDD assumes a less/non-technical people can help you write the tests or confirm that you have met the requirement. This usually involves Business Analyst or Pro

by fiveo 16y ago

BDD assumes a less/non-technical people can help you write the tests or confirm that you have met the requirement. This usually involves Business Analyst or Product Owner/Manager/Clients. While it's nice, I found that usually these people are either: 1) too lazy to do that (cause they pay you to do the technical stuff) or 2) don't have time cause they have things to do as well. I'm not suggesting that people should not do BDD or Acceptance Tests. But in situation where you cannot do that, it's not a big loss. TDD on the other hand, is the minimum requirement. As a side note, Transloadit may not have these people/roles so it's not a big of a deal for them.

ericHosick 16y ago
How about from this perspective: 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.
- fiveo 16y ago
  Is BDD = TDD? Or more like Acceptance Test? 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.

by fiveo 16y ago

ericHosick 16y ago

How about from this perspective: 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.

fiveo 16y ago
Is BDD = TDD? Or more like Acceptance Test? 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.