4 ms·

I think it would also behoove you to start using BDD in your development process. With BDD, you get a one-to-many correlation between behavior and code. This al

I think it would also behoove you to start using BDD in your development process. With BDD, you get a one-to-many correlation between behavior and code. This also greatly improves on quality. I say this because quality can only be based against requirements. BDD forces the developer to have the behavioral requirements upfront. BDD allows you to take a given behavioral requirement and see all the code that supports that requirement and visa-versa. If a customer ever asks you, you can point to exactly where you are fulfilling that behavioral requirement in the source code. And BDD languages such as Gherkin are easy to read for most non-technical people. Of course, this isn't a replacement for TDD.

swombat 16y ago
I take the definition (proposed, usually, by BDD people like David Chelimsky and the like) that BDD is not fundamentally different from TDD. BDD is just TDD done right. As such, it makes little sense to propose using BDD "instead of" TDD. If you're doing TDD right, there's no benefit to "switching to BDD", other than a monstrous task of rewriting your tests using another set of sub-frameworks...
- ericHosick 16y ago
  I think there is quite a big difference, fundamentally, between BDD and TDD (though they are not mutually exclusive and do overlap). Let's try a quick example of a google maps type app: locating where you are and where you want to be. From BDD perspective, you get a mockup of the screen (could even be some non visual process) and this represents the behavior you want of the product: the behavioral requirements. From this mockup we can pull out all the behavior on that screen (or within that system). Feature: In order to see if I am where I want to be As a traveler I need to know my location. Scenario: At My Location Given I want to be at Lon XXXX Lat YYYY And I am at Log XXXX Lat YYYY Then I should see "You are There" Scenario: Not there Yet Given I want to be at Lon XXXX Lat YYYY And I am at Log XXXX Lat YYYY2 Then I should see "You have 4 meters to go". From this behavior we can then build out the system which inevitably leads to fine grained software specific behavior which should be tested using TDD such as: it should "calculate the distance between two points correct" In the case of BDD, we don't worry about how the two points are calculated nor if it is even done correctly (we don't need full fringe test coverage in BDD). We are able to assume that the underlying calculations will be correct. We do need to make sure that the behavior of the system as a whole is working correctly. In this case, we are assuming if the calculation is incorrect we will not see "You are There" on the screen. Why was it incorrect? Doesn't matter. That specific behavior, the calculation, was driven by Tests. Personally, and for efficiency, it is really important to use both in a project and not look at BDD as "TDD done right." Just my two cents.
felixge 16y ago
I think BDD would be a nice addition to our system tests. However, I have not worked much in Ruby, and from the outside it is hard to tell whether those cute DSL's are more poetry or business ; ). (Don't get me wrong, I love cute code - but not at the price of simplicity)
- steveklabnik 16y ago
  BDD isn't a Ruby library, it's a slight change in focus on what you test. As your sibling says, it's really just "TDD done correctly." Here's the primary text: http://blog.dannorth.net/introducing-bdd/ http://blog.dannorth.net/introducing-bdd/
  - felixge 16y ago
    I know it's not a ruby library, but I also know I don't know a lot about it. Thanks for the link, I'll try to see if I can extract some usable concepts from it : ).
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.

swombat 16y ago

I take the definition (proposed, usually, by BDD people like David Chelimsky and the like) that BDD is not fundamentally different from TDD. BDD is just TDD done right. As such, it makes little sense to propose using BDD "instead of" TDD. If you're doing TDD right, there's no benefit to "switching to BDD", other than a monstrous task of rewriting your tests using another set of sub-frameworks...

ericHosick 16y ago
I think there is quite a big difference, fundamentally, between BDD and TDD (though they are not mutually exclusive and do overlap). Let's try a quick example of a google maps type app: locating where you are and where you want to be. From BDD perspective, you get a mockup of the screen (could even be some non visual process) and this represents the behavior you want of the product: the behavioral requirements. From this mockup we can pull out all the behavior on that screen (or within that system). Feature: In order to see if I am where I want to be As a traveler I need to know my location. Scenario: At My Location Given I want to be at Lon XXXX Lat YYYY And I am at Log XXXX Lat YYYY Then I should see "You are There" Scenario: Not there Yet Given I want to be at Lon XXXX Lat YYYY And I am at Log XXXX Lat YYYY2 Then I should see "You have 4 meters to go". From this behavior we can then build out the system which inevitably leads to fine grained software specific behavior which should be tested using TDD such as: it should "calculate the distance between two points correct" In the case of BDD, we don't worry about how the two points are calculated nor if it is even done correctly (we don't need full fringe test coverage in BDD). We are able to assume that the underlying calculations will be correct. We do need to make sure that the behavior of the system as a whole is working correctly. In this case, we are assuming if the calculation is incorrect we will not see "You are There" on the screen. Why was it incorrect? Doesn't matter. That specific behavior, the calculation, was driven by Tests. Personally, and for efficiency, it is really important to use both in a project and not look at BDD as "TDD done right." Just my two cents.

felixge 16y ago

I think BDD would be a nice addition to our system tests. However, I have not worked much in Ruby, and from the outside it is hard to tell whether those cute DSL's are more poetry or business ; ). (Don't get me wrong, I love cute code - but not at the price of simplicity)

steveklabnik 16y ago
BDD isn't a Ruby library, it's a slight change in focus on what you test. As your sibling says, it's really just "TDD done correctly." Here's the primary text: http://blog.dannorth.net/introducing-bdd/ http://blog.dannorth.net/introducing-bdd/
- felixge 16y ago
  I know it's not a ruby library, but I also know I don't know a lot about it. Thanks for the link, I'll try to see if I can extract some usable concepts from it : ).

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.