Behavior Driven Development - Versionsgeschichte

Wikiwormweb: /* growthexperiments-addlink-summary-summary:1|2|0 */

2024-08-30T12:11:12Z

Linkvorschlag-Funktion: 1 Link hinzugefügt.

← Nächstältere Version		Version vom 30. August 2024, 14:11 Uhr
Zeile 5:		Zeile 5:
	== Techniken des Behavior Driven Developments ==		== Techniken des Behavior Driven Developments ==
	Behavior Driven Development besteht aus folgenden Elementen:		Behavior Driven Development besteht aus folgenden Elementen:
	* Starke Einbeziehung der Stakeholder in den Prozess durch sogenannte Outside-In-Softwareentwicklung. Diese ist fokussiert auf die Erfüllung der Anforderungen der Auftraggeber, Enduser, Betrieb und Insider.		* Starke Einbeziehung der [[Stakeholder]] in den Prozess durch sogenannte Outside-In-Softwareentwicklung. Diese ist fokussiert auf die Erfüllung der Anforderungen der Auftraggeber, Enduser, Betrieb und Insider.
	* Textuelle Beschreibung des Verhaltens der Software und von Softwareteilen durch Fallbeispiele. Verwendung genormter Schlüsselwörter zur Markierung von Vorbedingungen, externen Verhaltens und gewünschten Verhaltens der Software.		* Textuelle Beschreibung des Verhaltens der Software und von Softwareteilen durch Fallbeispiele. Verwendung genormter Schlüsselwörter zur Markierung von Vorbedingungen, externen Verhaltens und gewünschten Verhaltens der Software.
	* Automatisierung dieser Fallbeispiele unter Verwendung von [[Mock-Objekt]]en zur Simulation von noch nicht implementierten Softwareteilen.		* Automatisierung dieser Fallbeispiele unter Verwendung von [[Mock-Objekt]]en zur Simulation von noch nicht implementierten Softwareteilen.

KlartextJan: /* Einzelnachweise Link Archivierung*/

2024-02-13T09:39:06Z

Einzelnachweise Link Archivierung

← Nächstältere Version		Version vom 13. Februar 2024, 11:39 Uhr
Zeile 1:		Zeile 1:
	'''Behavior Driven Development''' ('''BDD''', {{deS\|verhaltensgetriebene Softwareentwicklung}}), auch als '''Specification Driven Development''' ('''SDD''', {{deS\|anforderungsgetriebene Softwareentwicklung}}) bezeichnet, ist eine Technik der [[Agile Softwareentwicklung\|agilen Softwareentwicklung]], welche die Zusammenarbeit zwischen [[Qualitätsmanagement]] und [[Business-Analyse]] in Softwareentwicklungsprojekten stärkt. Beim Behavior Driven Development werden während der Anforderungsanalyse die Aufgaben, Ziele und Ergebnisse der Software in einer bestimmten Textform festgehalten, die später als automatisierte Tests ausgeführt werden kann. Damit kann die Software auf ihre korrekte Implementierung getestet werden. Die [[Softwareanforderung]]en werden dabei meist in „Wenn-dann“-Sätzen basierend auf der Sprache des [[Domain-driven Design]]s verfasst. Damit soll der Übergang zwischen der Sprache der Definition der fachlichen Anforderungen und der Programmiersprache, mittels derer die Anforderungen umgesetzt werden, erleichtert werden.		'''Behavior Driven Development''' ('''BDD''', {{deS\|verhaltensgetriebene Softwareentwicklung}}), auch als '''Specification Driven Development''' ('''SDD''', {{deS\|anforderungsgetriebene Softwareentwicklung}}) bezeichnet, ist eine Technik der [[Agile Softwareentwicklung\|agilen Softwareentwicklung]], welche die Zusammenarbeit zwischen [[Qualitätsmanagement]] und [[Business-Analyse]] in Softwareentwicklungsprojekten stärkt. Beim Behavior Driven Development werden während der Anforderungsanalyse die Aufgaben, Ziele und Ergebnisse der Software in einer bestimmten Textform festgehalten, die später als automatisierte Tests ausgeführt werden kann. Damit kann die Software auf ihre korrekte Implementierung getestet werden. Die [[Softwareanforderung]]en werden dabei meist in „Wenn-dann“-Sätzen basierend auf der Sprache des [[Domain-driven Design]]s verfasst. Damit soll der Übergang zwischen der Sprache der Definition der fachlichen Anforderungen und der Programmiersprache, mittels derer die Anforderungen umgesetzt werden, erleichtert werden.

	Behavior Driven Development wurde erstmals 2003 durch Dan North<ref name="Einführung">D. North, [http://dannorth.net/introducing-bdd Introducing Behaviour Driven Development]</ref> als Antwort auf [[testgetriebene Entwicklung]] beschrieben und hat sich seit damals weiterentwickelt.<ref>{{Internetquelle \|autor=Dan North et al. \|url=http://forums.pragprog.com/forums/95/topics/3035 \|titel=Question about Chapter 11: Writing software that matters \|sprache=en \|zitat=The phrase ‘BDD is TDD done well’, while a nice compliment, is a bit out of date. […] BDD has evolved considerably over the years into the methodology we describe in the book. Back when it was focused purely on the TDD space– around 2003-2004 – this was a valid description. Now it only covers a small part of the BDD proposition. \|abruf=2011-11-09 \|archiv-url=https://web.archive.org/web/20091107220359/http://forums.pragprog.com/forums/95/topics/3035 \|archiv-datum=2009-11-07 \|offline=ja \|archiv-bot=2022-10-09 13:32:07 InternetArchiveBot }}</ref> Dan North entwickelte auch das erste Framework für die Umsetzung von BDD, JBehave.<ref name="Einführung" />		Behavior Driven Development wurde erstmals 2003 durch Dan North<ref name="Einführung">D. North, [http://dannorth.net/introducing-bdd Introducing Behaviour Driven Development]</ref> als Antwort auf [[testgetriebene Entwicklung]] beschrieben und hat sich seit damals weiterentwickelt.<ref>{{Internetquelle \|autor=Dan North et al. \|url=http://forums.pragprog.com/forums/95/topics/3035 \|titel=Question about Chapter 11: Writing software that matters \|sprache=en \|offline=ja \|archiv-url=https://web.archive.org/web/20091107220359/http://forums.pragprog.com/forums/95/topics/3035 \|archiv-datum=2009-11-07 \|archiv-bot= \|abruf=2011-11-09 \|zitat=The phrase ‘BDD is TDD done well’, while a nice compliment, is a bit out of date. […] BDD has evolved considerably over the years into the methodology we describe in the book. Back when it was focused purely on the TDD space– around 2003-2004 – this was a valid description. Now it only covers a small part of the BDD proposition.}}</ref> Dan North entwickelte auch das erste Framework für die Umsetzung von BDD, JBehave.<ref name="Einführung" />

	== Techniken des Behavior Driven Developments ==		== Techniken des Behavior Driven Developments ==
Zeile 55:		Zeile 55:

	'''Ruby'''		'''Ruby'''
	* RBehave<ref name="rbehave">{{Internetquelle \|autor=Dan North \|url=http://dannorth.net/2007/06/introducing-rbehave \|titel=Introducing rbehave \|datum=2007-06-17 \|sprache=en \|~~abruf~~=~~2011-11-09~~ \|archiv-url=https://web.archive.org/web/20070620230359/http://dannorth.net/2007/06/introducing-rbehave \|archiv-datum=2007-06-20 ~~\|offline=ja~~ \|archiv-bot=~~2023~~-03-~~18 00:55:25 InternetArchiveBot~~ }}</ref>		* RBehave<ref name="rbehave">{{Internetquelle \|autor=Dan North \|url=http://dannorth.net/2007/06/introducing-rbehave \|titel=Introducing rbehave \|datum=2007-06-17 \|sprache=en \|offline=ja \|archiv-url=https://web.archive.org/web/20070620230359/http://dannorth.net/2007/06/introducing-rbehave \|archiv-datum=2007-06-20 \|archiv-bot= \|abruf=2011-11-09}}</ref>

	'''Python'''		'''Python'''

Matthias M.: /* Werkzeuge */ Projektwebsites sind keine geeignete WP:Belege, Rezeption für JGiven eingefügt

2023-12-08T12:10:45Z

Werkzeuge: Projektwebsites sind keine geeignete WP:Belege, Rezeption für JGiven eingefügt

← Nächstältere Version		Version vom 8. Dezember 2023, 14:10 Uhr
Zeile 75:		Zeile 75:
	* JBehave<ref name="jbehave">{{Internetquelle \|url=http://jbehave.org/ \|titel=JBehave \|sprache=en \|abruf=2018-09-23}}</ref>		* JBehave<ref name="jbehave">{{Internetquelle \|url=http://jbehave.org/ \|titel=JBehave \|sprache=en \|abruf=2018-09-23}}</ref>
	* Jnario<ref>{{Internetquelle \|url=http://jnario.org/ \|titel=Jnario Homepage \|sprache=en \|abruf=2013-01-30}}</ref>		* Jnario<ref>{{Internetquelle \|url=http://jnario.org/ \|titel=Jnario Homepage \|sprache=en \|abruf=2013-01-30}}</ref>
	* JGiven<ref>{{Internetquelle \|url=~~http~~://~~jgiven~~.~~org~~/ \|titel=JGiven \|sprache=en \|abruf=~~2015~~-03-07}}</ref>		* JGiven<ref>{{Internetquelle \|url=https://entwickler.de/java/lessons-learned \|autor=Marco Schulz \|titel=Behavior-driven Development: Akzeptanztests in Java mit JGiven \|werk=Java Magazin 2.2020 \|datum=2019-11-29 \|sprache=de-DE \|abruf=2023-12-08}}</ref>

	'''JavaScript / TypeScript'''		'''JavaScript / TypeScript'''

InternetArchiveBot: InternetArchiveBot hat 1 Archivlink(s) ergänzt und 0 Link(s) als defekt/tot markiert.) #IABot (v2.0.9.3

2023-03-18T00:55:25Z

InternetArchiveBot hat 1 Archivlink(s) ergänzt und 0 Link(s) als defekt/tot markiert.) #IABot (v2.0.9.3

← Nächstältere Version		Version vom 18. März 2023, 02:55 Uhr
Zeile 55:		Zeile 55:

	'''Ruby'''		'''Ruby'''
	* RBehave<ref name="rbehave">{{Internetquelle \|autor=Dan North \|url=http://dannorth.net/2007/06/introducing-rbehave \|titel=Introducing rbehave \|datum=2007-06-17 \|sprache=en \|abruf=2011-11-09}}</ref>		* RBehave<ref name="rbehave">{{Internetquelle \|autor=Dan North \|url=http://dannorth.net/2007/06/introducing-rbehave \|titel=Introducing rbehave \|datum=2007-06-17 \|sprache=en \|abruf=2011-11-09 \|archiv-url=https://web.archive.org/web/20070620230359/http://dannorth.net/2007/06/introducing-rbehave \|archiv-datum=2007-06-20 \|offline=ja \|archiv-bot=2023-03-18 00:55:25 InternetArchiveBot }}</ref>

	'''Python'''		'''Python'''

InternetArchiveBot: InternetArchiveBot hat 1 Archivlink(s) ergänzt und 0 Link(s) als defekt/tot markiert.) #IABot (v2.0.9.2

2022-10-09T13:32:07Z

InternetArchiveBot hat 1 Archivlink(s) ergänzt und 0 Link(s) als defekt/tot markiert.) #IABot (v2.0.9.2

← Nächstältere Version		Version vom 9. Oktober 2022, 15:32 Uhr
Zeile 1:		Zeile 1:
	'''Behavior Driven Development''' ('''BDD''', {{deS\|verhaltensgetriebene Softwareentwicklung}}), auch als '''Specification Driven Development''' ('''SDD''', {{deS\|anforderungsgetriebene Softwareentwicklung}}) bezeichnet, ist eine Technik der [[Agile Softwareentwicklung\|agilen Softwareentwicklung]], welche die Zusammenarbeit zwischen [[Qualitätsmanagement]] und [[Business-Analyse]] in Softwareentwicklungsprojekten stärkt. Beim Behavior Driven Development werden während der Anforderungsanalyse die Aufgaben, Ziele und Ergebnisse der Software in einer bestimmten Textform festgehalten, die später als automatisierte Tests ausgeführt werden kann. Damit kann die Software auf ihre korrekte Implementierung getestet werden. Die [[Softwareanforderung]]en werden dabei meist in „Wenn-dann“-Sätzen basierend auf der Sprache des [[Domain-driven Design]]s verfasst. Damit soll der Übergang zwischen der Sprache der Definition der fachlichen Anforderungen und der Programmiersprache, mittels derer die Anforderungen umgesetzt werden, erleichtert werden.		'''Behavior Driven Development''' ('''BDD''', {{deS\|verhaltensgetriebene Softwareentwicklung}}), auch als '''Specification Driven Development''' ('''SDD''', {{deS\|anforderungsgetriebene Softwareentwicklung}}) bezeichnet, ist eine Technik der [[Agile Softwareentwicklung\|agilen Softwareentwicklung]], welche die Zusammenarbeit zwischen [[Qualitätsmanagement]] und [[Business-Analyse]] in Softwareentwicklungsprojekten stärkt. Beim Behavior Driven Development werden während der Anforderungsanalyse die Aufgaben, Ziele und Ergebnisse der Software in einer bestimmten Textform festgehalten, die später als automatisierte Tests ausgeführt werden kann. Damit kann die Software auf ihre korrekte Implementierung getestet werden. Die [[Softwareanforderung]]en werden dabei meist in „Wenn-dann“-Sätzen basierend auf der Sprache des [[Domain-driven Design]]s verfasst. Damit soll der Übergang zwischen der Sprache der Definition der fachlichen Anforderungen und der Programmiersprache, mittels derer die Anforderungen umgesetzt werden, erleichtert werden.

	Behavior Driven Development wurde erstmals 2003 durch Dan North<ref name="Einführung">D. North, [http://dannorth.net/introducing-bdd Introducing Behaviour Driven Development]</ref> als Antwort auf [[testgetriebene Entwicklung]] beschrieben und hat sich seit damals weiterentwickelt.<ref>{{Internetquelle \|autor=Dan North et al. \|url=http://forums.pragprog.com/forums/95/topics/3035 \|titel=Question about Chapter 11: Writing software that matters \|sprache=en \|zitat=The phrase ‘BDD is TDD done well’, while a nice compliment, is a bit out of date. […] BDD has evolved considerably over the years into the methodology we describe in the book. Back when it was focused purely on the TDD space– around 2003-2004 – this was a valid description. Now it only covers a small part of the BDD proposition. \|abruf=2011-11-09}}</ref> Dan North entwickelte auch das erste Framework für die Umsetzung von BDD, JBehave.<ref name="Einführung" />		Behavior Driven Development wurde erstmals 2003 durch Dan North<ref name="Einführung">D. North, [http://dannorth.net/introducing-bdd Introducing Behaviour Driven Development]</ref> als Antwort auf [[testgetriebene Entwicklung]] beschrieben und hat sich seit damals weiterentwickelt.<ref>{{Internetquelle \|autor=Dan North et al. \|url=http://forums.pragprog.com/forums/95/topics/3035 \|titel=Question about Chapter 11: Writing software that matters \|sprache=en \|zitat=The phrase ‘BDD is TDD done well’, while a nice compliment, is a bit out of date. […] BDD has evolved considerably over the years into the methodology we describe in the book. Back when it was focused purely on the TDD space– around 2003-2004 – this was a valid description. Now it only covers a small part of the BDD proposition. \|abruf=2011-11-09 \|archiv-url=https://web.archive.org/web/20091107220359/http://forums.pragprog.com/forums/95/topics/3035 \|archiv-datum=2009-11-07 \|offline=ja \|archiv-bot=2022-10-09 13:32:07 InternetArchiveBot }}</ref> Dan North entwickelte auch das erste Framework für die Umsetzung von BDD, JBehave.<ref name="Einführung" />

	== Techniken des Behavior Driven Developments ==		== Techniken des Behavior Driven Developments ==

Dreizung: /* Techniken des Behavior Driven Developments */ Tippfehler

2021-12-08T17:40:33Z

Techniken des Behavior Driven Developments: Tippfehler

← Nächstältere Version		Version vom 8. Dezember 2021, 19:40 Uhr
Zeile 19:		Zeile 19:
	\|Autor=Gojko Adzic		\|Autor=Gojko Adzic
	\|Quelle=Bridging the Communication Gap		\|Quelle=Bridging the Communication Gap
	\|Übersetzung=Zusätzlich dazu, dass es schwieriger ist, sich auf wichtige Fragen zu konzentrieren, überspezifizieren Testskripte, welche das ''wie'' beschreiben, die Implementierung. Durch das Beschreiben wie etwas gemacht werden sollte, erlauben diese Tests es Entwicklern nicht, bessere Lösungen für ~~das selbe~~ Problem zu finden. Wenn Spezifikationen nur beschreiben ''was'' gemacht werden soll, dann haben Entwickler mehr Freiheit gute Lösungen zu implementieren.		\|Übersetzung=Zusätzlich dazu, dass es schwieriger ist, sich auf wichtige Fragen zu konzentrieren, überspezifizieren Testskripte, welche das ''wie'' beschreiben, die Implementierung. Durch das Beschreiben wie etwas gemacht werden sollte, erlauben diese Tests es Entwicklern nicht, bessere Lösungen für dasselbe Problem zu finden. Wenn Spezifikationen nur beschreiben ''was'' gemacht werden soll, dann haben Entwickler mehr Freiheit gute Lösungen zu implementieren.
	\|ref=<ref>{{Literatur \|Autor=Gojko Adzic \|Titel=Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing \|Verlag=Neuri Limited \|Datum=2009 \|ISBN=978-0-9556836-1-9 \|Seiten=79-80 \|Sprache=en \|Umfang=284}}</ref>}}		\|ref=<ref>{{Literatur \|Autor=Gojko Adzic \|Titel=Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing \|Verlag=Neuri Limited \|Datum=2009 \|ISBN=978-0-9556836-1-9 \|Seiten=79-80 \|Sprache=en \|Umfang=284}}</ref>}}

Jansan: /* Werkzeuge */

2021-09-16T16:47:28Z

Werkzeuge

← Nächstältere Version		Version vom 16. September 2021, 18:47 Uhr
Zeile 49:		Zeile 49:

	== Werkzeuge ==		== Werkzeuge ==
	Beim Einsatz von Behavior Driven Development benötigt man Werkzeuge (~~"Frameworks"~~), für die man das Verhalten der in den Szenarien auftretenden Schritte programmiert, sodass das Werkzeug die Szenarien interpretieren und gegen die umgesetzte Applikation ausführen kann. Die Werkzeuge selbst sind oft nur für bestimmte Programmiersprachen geeignet. Die bekanntesten Vertreter sind [[JBehave]], [[Framework for Integrated Test\|Framework for Integrated Test (FIT)]], [[FitNesse]], [[Concordion]] für Java und [[RBehave]], sowie [[Cucumber (Software)\|Cucumber]] für [[Ruby (Programmiersprache)\|Ruby]], Java und JavaScript.		Beim Einsatz von Behavior Driven Development benötigt man Werkzeuge („Frameworks“), für die man das Verhalten der in den Szenarien auftretenden Schritte programmiert, sodass das Werkzeug die Szenarien interpretieren und gegen die umgesetzte Applikation ausführen kann. Die Werkzeuge selbst sind oft nur für bestimmte Programmiersprachen geeignet. Die bekanntesten Vertreter sind [[JBehave]], [[Framework for Integrated Test\|Framework for Integrated Test (FIT)]], [[FitNesse]], [[Concordion]] für Java und [[RBehave]], sowie [[Cucumber (Software)\|Cucumber]] für [[Ruby (Programmiersprache)\|Ruby]], Java und JavaScript.

	'''C++'''		'''C++'''

Jansan: /* Techniken des Behavior Driven Developments */ Grammatikfehler korrigiert

2021-09-16T16:42:57Z

Techniken des Behavior Driven Developments: Grammatikfehler korrigiert

← Nächstältere Version		Version vom 16. September 2021, 18:42 Uhr
Zeile 5:		Zeile 5:
	== Techniken des Behavior Driven Developments ==		== Techniken des Behavior Driven Developments ==
	Behavior Driven Development besteht aus folgenden Elementen:		Behavior Driven Development besteht aus folgenden Elementen:
	* Starke Einbeziehung ~~von~~ Stakeholder in den Prozess durch sogenannte Outside-In-Softwareentwicklung. Diese ist fokussiert auf die Erfüllung der Anforderungen der Auftraggeber, Enduser, Betrieb und Insider.		* Starke Einbeziehung der Stakeholder in den Prozess durch sogenannte Outside-In-Softwareentwicklung. Diese ist fokussiert auf die Erfüllung der Anforderungen der Auftraggeber, Enduser, Betrieb und Insider.
	* Textuelle Beschreibung des Verhaltens der Software und von Softwareteilen durch Fallbeispiele. Verwendung genormter Schlüsselwörter zur Markierung von Vorbedingungen, externen Verhaltens und gewünschten Verhaltens der Software.		* Textuelle Beschreibung des Verhaltens der Software und von Softwareteilen durch Fallbeispiele. Verwendung genormter Schlüsselwörter zur Markierung von Vorbedingungen, externen Verhaltens und gewünschten Verhaltens der Software.
	* Automatisierung dieser Fallbeispiele unter Verwendung von [[Mock-Objekt]]en zur Simulation von noch nicht implementierten Softwareteilen.		* Automatisierung dieser Fallbeispiele unter Verwendung von [[Mock-Objekt]]en zur Simulation von noch nicht implementierten Softwareteilen.
Zeile 19:		Zeile 19:
	\|Autor=Gojko Adzic		\|Autor=Gojko Adzic
	\|Quelle=Bridging the Communication Gap		\|Quelle=Bridging the Communication Gap
	\|Übersetzung=Zusätzlich dazu, dass schwieriger ist sich auf wichtige Fragen zu konzentrieren, überspezifizieren Testskripte, welche das ''wie'' beschreiben, die Implementierung. Durch das Beschreiben wie etwas gemacht werden sollte, erlauben diese Tests es Entwicklern nicht, bessere Lösungen für das selbe Problem zu finden. Wenn Spezifikationen nur beschreiben ''was'' gemacht werden soll, dann haben Entwickler mehr Freiheit gute Lösungen zu implementieren.		\|Übersetzung=Zusätzlich dazu, dass es schwieriger ist, sich auf wichtige Fragen zu konzentrieren, überspezifizieren Testskripte, welche das ''wie'' beschreiben, die Implementierung. Durch das Beschreiben wie etwas gemacht werden sollte, erlauben diese Tests es Entwicklern nicht, bessere Lösungen für das selbe Problem zu finden. Wenn Spezifikationen nur beschreiben ''was'' gemacht werden soll, dann haben Entwickler mehr Freiheit gute Lösungen zu implementieren.
	\|ref=<ref>{{Literatur \|Autor=Gojko Adzic \|Titel=Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing \|Verlag=Neuri Limited \|Datum=2009 \|ISBN=978-0-9556836-1-9 \|Seiten=79-80 \|Sprache=en \|Umfang=284}}</ref>}}		\|ref=<ref>{{Literatur \|Autor=Gojko Adzic \|Titel=Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing \|Verlag=Neuri Limited \|Datum=2009 \|ISBN=978-0-9556836-1-9 \|Seiten=79-80 \|Sprache=en \|Umfang=284}}</ref>}}

Jansan: "ubiquitäre Sprache" schafft eher Verwirrung, also einfach "Sprache"

2021-09-16T16:40:51Z

"ubiquitäre Sprache" schafft eher Verwirrung, also einfach "Sprache"

← Nächstältere Version		Version vom 16. September 2021, 18:40 Uhr
Zeile 1:		Zeile 1:
	'''Behavior Driven Development''' ('''BDD''', {{deS\|verhaltensgetriebene Softwareentwicklung}}), auch als '''Specification Driven Development''' ('''SDD''', {{deS\|anforderungsgetriebene Softwareentwicklung}}) bezeichnet, ist eine Technik der [[Agile Softwareentwicklung\|agilen Softwareentwicklung]], welche die Zusammenarbeit zwischen [[Qualitätsmanagement]] und [[Business-Analyse]] in Softwareentwicklungsprojekten stärkt. Beim Behavior Driven Development werden während der Anforderungsanalyse die Aufgaben, Ziele und Ergebnisse der Software in einer bestimmten Textform festgehalten, die später als automatisierte Tests ausgeführt werden kann. Damit kann die Software auf ihre korrekte Implementierung getestet werden. Die [[Softwareanforderung]]en werden dabei meist in „Wenn-dann“-Sätzen basierend auf der ~~ubiquitären~~ Sprache des [[Domain-driven Design]]s verfasst. Damit soll der Übergang zwischen der Sprache der Definition der fachlichen Anforderungen und der Programmiersprache, mittels derer die Anforderungen umgesetzt werden, erleichtert werden.		'''Behavior Driven Development''' ('''BDD''', {{deS\|verhaltensgetriebene Softwareentwicklung}}), auch als '''Specification Driven Development''' ('''SDD''', {{deS\|anforderungsgetriebene Softwareentwicklung}}) bezeichnet, ist eine Technik der [[Agile Softwareentwicklung\|agilen Softwareentwicklung]], welche die Zusammenarbeit zwischen [[Qualitätsmanagement]] und [[Business-Analyse]] in Softwareentwicklungsprojekten stärkt. Beim Behavior Driven Development werden während der Anforderungsanalyse die Aufgaben, Ziele und Ergebnisse der Software in einer bestimmten Textform festgehalten, die später als automatisierte Tests ausgeführt werden kann. Damit kann die Software auf ihre korrekte Implementierung getestet werden. Die [[Softwareanforderung]]en werden dabei meist in „Wenn-dann“-Sätzen basierend auf der Sprache des [[Domain-driven Design]]s verfasst. Damit soll der Übergang zwischen der Sprache der Definition der fachlichen Anforderungen und der Programmiersprache, mittels derer die Anforderungen umgesetzt werden, erleichtert werden.

	Behavior Driven Development wurde erstmals 2003 durch Dan North<ref name="Einführung">D. North, [http://dannorth.net/introducing-bdd Introducing Behaviour Driven Development]</ref> als Antwort auf [[testgetriebene Entwicklung]] beschrieben und hat sich seit damals weiterentwickelt.<ref>{{Internetquelle \|autor=Dan North et al. \|url=http://forums.pragprog.com/forums/95/topics/3035 \|titel=Question about Chapter 11: Writing software that matters \|sprache=en \|zitat=The phrase ‘BDD is TDD done well’, while a nice compliment, is a bit out of date. […] BDD has evolved considerably over the years into the methodology we describe in the book. Back when it was focused purely on the TDD space– around 2003-2004 – this was a valid description. Now it only covers a small part of the BDD proposition. \|abruf=2011-11-09}}</ref> Dan North entwickelte auch das erste Framework für die Umsetzung von BDD, JBehave.<ref name="Einführung" />		Behavior Driven Development wurde erstmals 2003 durch Dan North<ref name="Einführung">D. North, [http://dannorth.net/introducing-bdd Introducing Behaviour Driven Development]</ref> als Antwort auf [[testgetriebene Entwicklung]] beschrieben und hat sich seit damals weiterentwickelt.<ref>{{Internetquelle \|autor=Dan North et al. \|url=http://forums.pragprog.com/forums/95/topics/3035 \|titel=Question about Chapter 11: Writing software that matters \|sprache=en \|zitat=The phrase ‘BDD is TDD done well’, while a nice compliment, is a bit out of date. […] BDD has evolved considerably over the years into the methodology we describe in the book. Back when it was focused purely on the TDD space– around 2003-2004 – this was a valid description. Now it only covers a small part of the BDD proposition. \|abruf=2011-11-09}}</ref> Dan North entwickelte auch das erste Framework für die Umsetzung von BDD, JBehave.<ref name="Einführung" />

Jansan: Überlanger Satz --> zwei Sätze

2021-09-16T16:38:34Z

Überlanger Satz --> zwei Sätze

← Nächstältere Version		Version vom 16. September 2021, 18:38 Uhr
Zeile 1:		Zeile 1:
	'''Behavior Driven Development''' ('''BDD''', {{deS\|verhaltensgetriebene Softwareentwicklung}}), auch als '''Specification Driven Development''' ('''SDD''', {{deS\|anforderungsgetriebene Softwareentwicklung}}) bezeichnet, ist eine Technik der [[Agile Softwareentwicklung\|agilen Softwareentwicklung]], welche die Zusammenarbeit zwischen [[Qualitätsmanagement]] und [[Business-Analyse]] in Softwareentwicklungsprojekten stärkt. Beim Behavior Driven Development werden während der Anforderungsanalyse die Aufgaben, Ziele und Ergebnisse der Software in einer bestimmten Textform festgehalten, die später als automatisierte Tests ausgeführt werden kann ~~und~~ ~~damit~~ die Software auf ihre korrekte Implementierung getestet werden ~~kann~~. Die [[Softwareanforderung]]en werden dabei meist in „Wenn-dann“-Sätzen basierend auf der ubiquitären Sprache des [[Domain-driven Design]]s verfasst. Damit soll der Übergang zwischen der Sprache der Definition der fachlichen Anforderungen und der Programmiersprache, mittels derer die Anforderungen umgesetzt werden, erleichtert werden.		'''Behavior Driven Development''' ('''BDD''', {{deS\|verhaltensgetriebene Softwareentwicklung}}), auch als '''Specification Driven Development''' ('''SDD''', {{deS\|anforderungsgetriebene Softwareentwicklung}}) bezeichnet, ist eine Technik der [[Agile Softwareentwicklung\|agilen Softwareentwicklung]], welche die Zusammenarbeit zwischen [[Qualitätsmanagement]] und [[Business-Analyse]] in Softwareentwicklungsprojekten stärkt. Beim Behavior Driven Development werden während der Anforderungsanalyse die Aufgaben, Ziele und Ergebnisse der Software in einer bestimmten Textform festgehalten, die später als automatisierte Tests ausgeführt werden kann. Damit kann die Software auf ihre korrekte Implementierung getestet werden. Die [[Softwareanforderung]]en werden dabei meist in „Wenn-dann“-Sätzen basierend auf der ubiquitären Sprache des [[Domain-driven Design]]s verfasst. Damit soll der Übergang zwischen der Sprache der Definition der fachlichen Anforderungen und der Programmiersprache, mittels derer die Anforderungen umgesetzt werden, erleichtert werden.

	Behavior Driven Development wurde erstmals 2003 durch Dan North<ref name="Einführung">D. North, [http://dannorth.net/introducing-bdd Introducing Behaviour Driven Development]</ref> als Antwort auf [[testgetriebene Entwicklung]] beschrieben und hat sich seit damals weiterentwickelt.<ref>{{Internetquelle \|autor=Dan North et al. \|url=http://forums.pragprog.com/forums/95/topics/3035 \|titel=Question about Chapter 11: Writing software that matters \|sprache=en \|zitat=The phrase ‘BDD is TDD done well’, while a nice compliment, is a bit out of date. […] BDD has evolved considerably over the years into the methodology we describe in the book. Back when it was focused purely on the TDD space– around 2003-2004 – this was a valid description. Now it only covers a small part of the BDD proposition. \|abruf=2011-11-09}}</ref> Dan North entwickelte auch das erste Framework für die Umsetzung von BDD, JBehave.<ref name="Einführung" />		Behavior Driven Development wurde erstmals 2003 durch Dan North<ref name="Einführung">D. North, [http://dannorth.net/introducing-bdd Introducing Behaviour Driven Development]</ref> als Antwort auf [[testgetriebene Entwicklung]] beschrieben und hat sich seit damals weiterentwickelt.<ref>{{Internetquelle \|autor=Dan North et al. \|url=http://forums.pragprog.com/forums/95/topics/3035 \|titel=Question about Chapter 11: Writing software that matters \|sprache=en \|zitat=The phrase ‘BDD is TDD done well’, while a nice compliment, is a bit out of date. […] BDD has evolved considerably over the years into the methodology we describe in the book. Back when it was focused purely on the TDD space– around 2003-2004 – this was a valid description. Now it only covers a small part of the BDD proposition. \|abruf=2011-11-09}}</ref> Dan North entwickelte auch das erste Framework für die Umsetzung von BDD, JBehave.<ref name="Einführung" />