Jump to content

Talk:Behavior-driven development

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Lack of context

[edit]

Let's talk about it before speedily deleting this article again... I'm sorry the first version was so information free... I just wanted to create a space to discuss the topic. — Preceding unsigned comment added by KellyCoinGuy (talk • contribs) 22:53, 21 October 2005 (UTC)[reply]

I've updated the article. Maybe the context message can go now. — Preceding unsigned comment added by 217.136.137.161 (talk) 16:45, 7 May 2006 (UTC)[reply]

The message can't go! The article, especially the beginning, is in terrible condition. --Mislav 22:04, 12 October 2006 (UTC)[reply]

Dave Astels

[edit]

Dave Astels also influences BDD. See his ideas and framework (at the moment in Ruby) in this video: Beyond Test Driven Development - Behaviour Driven Development ( 302 MB, 47:40 min ) Google TechTalks March 17, 2006 [1]. --Erkan Yilmaz 20:31, 11 November 2006 (UTC)[reply]

I'm dubious about the accuracy of this article. Many of the things it says about BDD are things I thought were already true of test-driven development. Needs more cites. —Preceding unsigned comment added by 24.6.102.150 (talk • contribs) 01:02, 18 March 2007

Update

[edit]

So, I just made some massive changes to this. Mostly it's based on Dan's stuff, together with some things from my blog and the XP list on Yahoo, that I know he's agreed with. Will add some in-text citations as soon as I have time.

Hope this serves as a good base for further edits!

Featheredwings (talk) 09:27, 18 February 2008 (UTC)[reply]

What is the relationship with traditional specification as language (CLU, Eiffel)?

[edit]

Consider representation invariants in a language such as CLU, or invariants in design-by-contract as in Eiffel.

These methods of development are similar to Behavior Driven Development. First one creates a specification for behavior, then the implementation of that behavior. The difference seems to be that there is less danger of destroying encapsulation when the specification is only for externally visible behavior. That is, the behavior of encapsulated details should be private, and should not require making those details public.

Has anyone written about the parallel between classic "executable specification" and Behavior Driven Development? Should something go in this article? --Frank Hileman 22:14, 26 September 2007 (UTC)[reply]

What about the Program Document Language (PDL) that was popular in the 1980'sSwgmk (talk) 22:53, 14 April 2018 (UTC)[reply]

Ubiquitous Language

[edit]

I'm not clear on the relationship to the ubiquitous language. Is BDD forming a ubiquitous language for testing or if you are practicing DDD with BDD is the ubiquitous language used in the tests? —Preceding unsigned comment added by 82.41.217.214 (talk) 21:46, 20 February 2008 (UTC)[reply]

A team should use the same verbiage for the same things - from the database to the view to the verbal conversations - following their client's lead with domain-specific jargon. That is ubiquitous language, and storytests are just one layer that should reinforce this vocabulary. —Preceding unsigned comment added by 98.175.108.199 (talk) 01:34, 9 March 2010 (UTC)[reply]

Seems to me that an explicit requirement to include a clear VERB-OBJECT structure in the descriptions would be helpful in ensuring it is clear what process is being done to what entity. — Preceding unsigned comment added by Lucchase (talk • contribs) 18:37, 22 August 2013 (UTC)[reply]

How does this differ from TDD?

[edit]

I'm not sure what the difference is between this and TDD. Can an expert add a section please 86.54.187.18 (talk) 16:31, 21 January 2009 (UTC) In fact it feels a bit like Dan North's take on TDD. —Preceding unsigned comment added by 86.54.187.18 (talk) 16:33, 21 January 2009 (UTC)[reply]

answered in the current version - it's TDD written in client-readable prose. See "literate programming" —Preceding unsigned comment added by 98.175.108.199 (talk) 01:36, 9 March 2010 (UTC)[reply]

Rename as "Behavior-driven development"?

[edit]
The following discussion is an archived discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

The result of the move request was: moved. Unopposed for a week and appears to be in line with WP:CAPS, WP:HYPHEN and other related articles. Jenks24 (talk) 10:05, 25 June 2012 (UTC)[reply]

Behavior Driven Development → Behavior-driven development – Test-driven development has set a precedent (I think). Other articles in Category:Software development philosophies that are not book titles follow WP:LOWERCASE. This page should follow that form and be named Behavior-driven development. --DavidBiesack (talk) 13:29, 18 June 2012 (UTC)[reply]

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

Use British English spelling for BDD

[edit]

In the "Introducing BDD" article the term is coined as "behaviour-driven development". The rest of the article seems to be in American English, but the term should always be in British English according to Wikipedia:Manual of style#National varieties of English. Spur (talk) 01:43, 4 July 2012 (UTC)[reply]

Gherkin is no longer specific to Cucumber

[edit]

It was originated by Cucumber, and the argument could certainly be made that it is still primarily used for Cucumber, but the Gherkin project's own wiki specifies that it feeds / is supported by a fairly wide set of other languages and tools.

Given that, should there be a sentence specifically and explicitly mentioning that it is exclusive to Cucumber? See here for more details: https://github.com/cucumber/gherkin/wiki/Tool-Support — Preceding unsigned comment added by 84.246.168.11 (talk) 16:44, 25 April 2013 (UTC)[reply]

Meaningless and imprecise phrasing

[edit]

I understand the whole Agile movement is very wishy-washy and full-to-bursting with buzzword-touting consultants. Does this article really have to be similarly devoid of information and specificity? — Preceding unsigned comment added by 82.9.176.129 (talk) 18:27, 10 August 2013 (UTC)[reply]

Here we are 2018 and the text is still imprecise. Second paragraph should be removed and the rest of the introduction re-written.--Charrua85 (talk) 11:22, 5 January 2018 (UTC)[reply]

TDD wrongly represented?

[edit]

The article has it that "TDD essentially states ...: define a test set ... first; then implement the unit; finally verify that ... the tests succeed."

My understanding of TDD is that a), contrary to the above, each test is to be specified separately, immediately followed by implementation of what is in scope of the test and verification of the outcome; and b) this way of working is the essence (!) of TDD.

Does anyone object to changing this to represent TDD better, do you feel that saying "essentially states" prevents this from being an oversimplification? Oliver Gramberg (talk) 08:09, 27 February 2014 (UTC)[reply]

IMO, unless there's real value to define TDD in this article, just reference the TDD article. DRY Stevebroshar (talk) 14:13, 16 April 2024 (UTC)[reply]

Business and Stakeholder driven via User Stories / BDD useful only for high-level business domain logic?

[edit]

Reading the article it suggests that the key drivers for BDD are the stakeholders but typically they are totally clueless about everything outside the business domain. For example if you want to use TDD on non-business domain units such as form or graphics composition libraries interopability libraries import export libraries application frameworks or pretty much any other component developed that is generic enough to satisfy a projects architecture - why would you even want to come up with a convaluted warping of a user story to somehow justify reading or writing a byte of data somewhere or another? ZhuLien 66.249.80.203 (talk) 16:13, 5 March 2014 (UTC)[reply]

Indeed, the approach explained in the main article lacks sections on its scope, criticism. Can the approach itself be falsified to show its limits? If this concern is disregarded by the proponents of BDD, they look more like prophets than scientists. --ilgiz (talk) 09:51, 29 February 2020 (UTC)[reply]

External links section moved from article

[edit]

In case there's something here that could be used for content verification or expansion: --Ronz (talk) 18:49, 19 January 2017 (UTC)[reply]

Shouldn't it be told that there are essentially two levels for BDD?

[edit]

Like the title says, there are two levels of BDD:

  1. Acceptance Testing => Something like Cucumber and JBehavior
  2. Unit Testing => Something like RSpec.

And they both have different terms that one should use... Maybe this article should be changed to reflect that. 2001:8A0:7F0F:3601:899C:15B8:A86A:4242 (talk) 15:25, 14 August 2017 (UTC)[reply]

Lack of information

[edit]

I was about to add my humble opinion about this article, but I see from the "Talk" here that many people agree that the article is rather meaningless. Or maybe the subject (BDD) is meaningless and vague. How about "BDD is just having the testers talk to the users..." I need to know what BDD is because I am about to go on a job interview and BDD is one of the requirements. — Preceding unsigned comment added by 2601:14d:4101:9d70:59c0:ad7f:6682:537 (talk) 13:14, 25 July 2019 (UTC)[reply]

"SHE QC" and "The Three Amigos"

[edit]

I have removed the recent addition of "SHE QC" as new technique. First of all, the edit seems to be in violation of our "conflict of interest" guideline at WP:COI. Such edits should generally be suggested on article talk by interested COI editors. Secondly, conference schedules and course summaries are not independent reliable sources. To establish the relevance of this new technique, someone else besides its inventor should have written about it in some detail. Wikipedia is an encyclopedia and covers established knowledge, not every minor new development or recent research that hasn't been widely discussed yet in other reliable publications. I have left the "The Three Amigos" part in for now, although the sources for these paragraphs are also relatively thin and/or not fully independent. Please discuss the removed content and the suitability of the remaining content here, if needed. GermanJoe (talk) 14:18, 3 June 2019 (UTC)[reply]

I removed it again, sharing the same concerns.
I removed the Example Mapping section for the same reasons. It's not clear mention is WP:DUE even if it was rewritten to not be promotional. --Ronz (talk) 03:31, 14 August 2019 (UTC)[reply]

Why does this read like an advertisement?

[edit]

This article has a huge slant. Instead of a description of BDD,the what, where, when, why. It reads like Ron Popeil trying to sell you something. 6cadc1f740 (talk) 14:59, 23 January 2024 (UTC)[reply]

Why? Human nature. ... I assume you are suggesting it shouldn't have that slant. Rather than complaining about the content I suggest you improve it. ... I think the lead defines BDD with what are purported benefits. I think the lead should be re-written to say what it is and then later to list the pluses as described by supporters. In particular, the last lead paragraph, "BDD is largely facilitated through the use of a simple domain-specific language (DSL) using natural-language constructs (e.g., English-like sentences) that can express the behaviour and the expected outcomes" is a good start for a definition. Stevebroshar (talk) 14:25, 16 April 2024 (UTC)[reply]
[edit]

The article states "BDD is considered a refinement of test-driven development (TDD)" but it's really not.

TDD is a process for writing tests BDD is a way of writing tests that describe a behaviour.

BDD is about behaviour, how does a block of software behave, given various conditions. A BDD test will involve many component or use mocks to emulate components. A BDD test would be made up of smaller components that have already had TDD applied. On the other hand, the TDD process by which you write unit tests, is about small incremental tests. Given certain input data, what is the expected output, one by one. TDD tests very small blocks of code, one at a time, until all the tests pass.

You also have to write the test differently by necessity. TDD is done line by line, given input test the output. Red/Green Refactor. It shapes the codebase as you go with two initial clients of the code. BDD requires a more complex structure, before a test can pass, and the individual components the make up the behaviour, should be tested first with TDD.

Pretty much the only real connection is the terminology adapted from TDD, and the structure of test classes and how that is set up. They look similar, but they are not testing the same things, nore do they really borrow from one another in terms of process. Bpappin (talk) 21:01, 7 August 2024 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Behavior-driven_development&oldid=1249582893"