Behaviour Driven Development (BDD) - Revision history

Mmusij: /* See Also */

2020-04-30T23:54:46Z

Mmusij: /* Challenges */

2019-01-21T06:10:44Z

Challenges

← Older revision		Revision as of 06:10, 21 January 2019
Line 30:		Line 30:

	==Challenges==		==Challenges==
	* Time taken to write tests can be exhaustive when compared to new code development time and may be very tempting to skip tests and just write code.		* Time taken to write tests can be exhaustive when compared to new code development time and may be very tempting to skip writing feature definitions and tests and just write code.
	* New testing skills may need to be introduced to developers, as they are now tasked with providing enough test coverage of their code. Boundary value analysis for example, may be a new skill to be acquired by the developers to ensure that they have sufficient test coverage.		* New testing skills may need to be introduced to developers, as they are now tasked with providing enough test coverage of their code. Boundary value analysis for example, may be a new skill to be acquired by the developers to ensure that they have sufficient test coverage.
	* The number of rainy day ~~unit~~ tests when compared to the number of sunny tests has been quoted as being as much as 10 rainy day to 1 sunny day, which may be a new discipline for developers.		* The number of rainy day tests when compared to the number of sunny tests has been quoted as being as much as 10 rainy day to 1 sunny day, which may be a new discipline for developers.
	* For extensive suites of unit tests, these may be overwhelming to maintain and keep current. Hence, refactoring tests may be just as important as refactoring code.		* For extensive suites of unit tests, these may be overwhelming to maintain and keep current. Hence, refactoring tests may be just as important as refactoring code.
			* Teams need a collaborative approach to write good feature definitions that align with the functional intentions as well as writing appropriate unit tests, and so collectively should have cross functional skills considering the high level functional needs and the low level technical needs.

	==See Also==		==See Also==

Mmusij: /* Benefits */

2019-01-21T06:08:26Z

Benefits

← Older revision		Revision as of 06:08, 21 January 2019
Line 23:		Line 23:

	==Benefits==		==Benefits==
	* Refactoring and enhancing ~~code~~ with full suites of unit tests can be done quickly as running the unit tests provides immediate feedback as to whether there are any issues		* Refactoring and enhancing the testable specs with full suites of unit tests can be done quickly as running the unit tests provides immediate feedback as to whether there are any issues
	* Other forms of testing such as functional testing and integration testing benefit from code that has been hardened with unit tests		* Other forms of testing such as functional testing and integration testing benefit from code that has been hardened with unit tests
	* Development efforts tend to be more focussed to satisfy the expected behaviour in ~~tests~~ rather than over developing code		* Development efforts tend to be more focussed to satisfy the expected behaviour in feature definitions rather than over developing code
	* If ~~refatoring~~ is incorporated well during the ~~TDD~~ cycles the code design grows in an elegant form that meets the expected behaviour rather than introducing assumptions, which may later be realised as constraints.		* If refactoring is incorporated well during the BDD cycles the code design grows in an elegant form that meets the expected behaviour rather than introducing assumptions, which may later be realised as constraints.
	* A suite of passed tests provides a very good level of confidence in the team that their code works		* A suite of passed tests provides a very good level of confidence in the team that their code works

Mmusij: /* Behaviour Driven Development Cycle */

2019-01-21T06:07:22Z

Behaviour Driven Development Cycle

← Older revision		Revision as of 06:07, 21 January 2019
Line 19:		Line 19:
	## Refactor any code that needs refactoring. N.B. If code is duplicated in more than one area then this may suggest that the code should be refactored. The eradication of technical debt and evolution towards an elegant design may also influence refactoring efforts. Unit tests can also be refactored for improved maintainability.		## Refactor any code that needs refactoring. N.B. If code is duplicated in more than one area then this may suggest that the code should be refactored. The eradication of technical debt and evolution towards an elegant design may also influence refactoring efforts. Unit tests can also be refactored for improved maintainability.
	## Goto the first step. N.B. Many small TDD cycles tend to work best especially when incorporating refactoring efforts rather than writing a bulk of tests, then writing a bulk of code and then having to fix a bulk of failed tests.		## Goto the first step. N.B. Many small TDD cycles tend to work best especially when incorporating refactoring efforts rather than writing a bulk of tests, then writing a bulk of code and then having to fix a bulk of failed tests.
	# ~~Finally refactoring~~ the feature ~~definition~~ as needed.		# Refactor the suite of feature definitions to update existing ones or add new ones as needed
			# Repeat the process to refine the feature definitions and associated tests

	==Benefits==		==Benefits==

Mmusij at 06:05, 21 January 2019

2019-01-21T06:05:13Z

← Older revision		Revision as of 06:05, 21 January 2019
Line 10:		Line 10:

	# The cycle of BDD starts with writing a feature definition or testable spec using the [[User Stories#Gherkin Format\|Gherkin Format]] to outline the pre-conditions, actions and expected results		# The cycle of BDD starts with writing a feature definition or testable spec using the [[User Stories#Gherkin Format\|Gherkin Format]] to outline the pre-conditions, actions and expected results
	## Tests can be parameterised to cover boundary conditions and cater for rainy day tests etc.		#* Tests can be parameterised to cover boundary conditions and cater for rainy day tests etc.
	# The feature definition is then used by a BDD framework such as [https://docs.cucumber.io/ Cucumber] or [https://specflow.org/ SpecFlow] for example to create step definitions that are unit testing stubs that correspond to the feature definition tests		# The feature definition is then used by a BDD framework such as [https://docs.cucumber.io/ Cucumber] or [https://specflow.org/ SpecFlow] for example to create step definitions that are unit testing stubs that correspond to the feature definition tests
	# The step definitions can then be completed and used to either run specific unit tests or call other existing unit tests.		# The step definitions can then be completed and used to either run specific unit tests or call other existing unit tests.
			# From this point the unit tests can be defined as with [[Test Driven Development (TDD)]]:
			## The next step is to run the suite of tests and determine which ones fail
			## If a test fails then write some code to resolve the test failure. N.B. If a rainy day test receives an expected exception, then this is a pass, in that, this is expected behaviour. ## If it received a different exception or no exception at all, then this would be deviating away from the expected behaviour stated in the unit test, and hence, would be a failed test.
	# The next step is to run the suite of tests and determine which ones fail		## Next run the tests again to ensure that the test suite passes
	# If a test fails then write some code to resolve the test failure. N.B. If a rainy day test receives an expected exception, then this is a pass, in that, this is expected behaviour. # If it received a different exception or no exception at all, then this would be deviating away from the expected behaviour stated in the unit test, and hence, would be a failed test.		## Refactor any code that needs refactoring. N.B. If code is duplicated in more than one area then this may suggest that the code should be refactored. The eradication of technical debt and evolution towards an elegant design may also influence refactoring efforts. Unit tests can also be refactored for improved maintainability.
	# Next run the tests again to ensure that the test suite passes		## Goto the first step. N.B. Many small TDD cycles tend to work best especially when incorporating refactoring efforts rather than writing a bulk of tests, then writing a bulk of code and then having to fix a bulk of failed tests.
	# Refactor any code that needs refactoring. N.B. If code is duplicated in more than one area then this may suggest that the code should be refactored. The eradication of technical debt and evolution towards an elegant design may also influence refactoring efforts. Unit tests can also be refactored for improved maintainability.		# Finally refactoring the feature definition as needed.
	# Goto the first step. N.B. Many small TDD cycles tend to work best especially when incorporating refactoring efforts rather than writing a bulk of tests, then writing a bulk of code and then having to fix a bulk of failed tests.

	==Benefits==		==Benefits==

Mmusij at 06:03, 21 January 2019

2019-01-21T06:03:07Z

← Older revision		Revision as of 06:03, 21 January 2019
Line 10:		Line 10:

	# The cycle of BDD starts with writing a feature definition or testable spec using the [[User Stories#Gherkin Format\|Gherkin Format]] to outline the pre-conditions, actions and expected results		# The cycle of BDD starts with writing a feature definition or testable spec using the [[User Stories#Gherkin Format\|Gherkin Format]] to outline the pre-conditions, actions and expected results
	unit ~~test~~ that ~~encapsulates~~ the ~~expected behaviour, sunny day~~ and ~~rainy day,~~ to ~~be satisfied by the intended code construct~~.		## Tests can be parameterised to cover boundary conditions and cater for rainy day tests etc.
			# The feature definition is then used by a BDD framework such as [https://docs.cucumber.io/ Cucumber] or [https://specflow.org/ SpecFlow] for example to create step definitions that are unit testing stubs that correspond to the feature definition tests
			# The step definitions can then be completed and used to either run specific unit tests or call other existing unit tests.



	# The next step is to run the suite of tests and determine which ones fail		# The next step is to run the suite of tests and determine which ones fail
	# If a test fails then write some code to resolve the test failure. N.B. If a rainy day test receives an expected exception, then this is a pass, in that, this is expected behaviour. # If it received a different exception or no exception at all, then this would be deviating away from the expected behaviour stated in the unit test, and hence, would be a failed test.		# If a test fails then write some code to resolve the test failure. N.B. If a rainy day test receives an expected exception, then this is a pass, in that, this is expected behaviour. # If it received a different exception or no exception at all, then this would be deviating away from the expected behaviour stated in the unit test, and hence, would be a failed test.

Mmusij: /* References */

2019-01-21T05:56:26Z

References

← Older revision		Revision as of 05:56, 21 January 2019
Line 35:		Line 35:

	==References==		==References==
			# [https://docs.cucumber.io/gherkin/reference/ https://docs.cucumber.io/gherkin/reference/], accessed 21 Jan 2019
	# Test Driven Development: By Example, Kent Beck, 2001		# Test Driven Development: By Example, Kent Beck, 2001
	# Extreme Programming Explained, Kent Beck and Cynthia Andres, 2004		# Extreme Programming Explained, Kent Beck and Cynthia Andres, 2004

Mmusij: /* Behaviour Driven Development Cycle */

2019-01-21T05:56:04Z

Behaviour Driven Development Cycle

← Older revision		Revision as of 05:56, 21 January 2019
Line 9:		Line 9:
	[[File:BDD.jpg\|500px\|Behaviour Driven Development (BDD)]]		[[File:BDD.jpg\|500px\|Behaviour Driven Development (BDD)]]

	# The cycle of BDD starts with writing a feature definition or testable spec using the [[User Stories#Gherkin Format\|Gherkin Format]] to outline the pre-conditions and ~~expectations~~		# The cycle of BDD starts with writing a feature definition or testable spec using the [[User Stories#Gherkin Format\|Gherkin Format]] to outline the pre-conditions, actions and expected results
	unit test that encapsulates the expected behaviour, sunny day and rainy day, to be satisfied by the intended code construct.		unit test that encapsulates the expected behaviour, sunny day and rainy day, to be satisfied by the intended code construct.
	# The next step is to run the suite of tests and determine which ones fail		# The next step is to run the suite of tests and determine which ones fail

Mmusij at 05:53, 21 January 2019

2019-01-21T05:53:53Z

← Older revision		Revision as of 05:53, 21 January 2019
Line 7:		Line 7:
	==Behaviour Driven Development Cycle==		==Behaviour Driven Development Cycle==

	[[File:~~Behaviour_Driven_Development_(~~BDD).jpg\|500px\|Behaviour Driven Development (BDD)]]		[[File:BDD.jpg\|500px\|Behaviour Driven Development (BDD)]]

	# The cycle of BDD starts with writing a feature definition or testable spec using the [[Gherkin Format]]		# The cycle of BDD starts with writing a feature definition or testable spec using the [[User Stories#Gherkin Format\|Gherkin Format]] to outline the pre-conditions and expectations
	unit test that encapsulates the expected behaviour, sunny day and rainy day, to be satisfied by the intended code construct.		unit test that encapsulates the expected behaviour, sunny day and rainy day, to be satisfied by the intended code construct.
	# The next step is to run the suite of tests and determine which ones fail		# The next step is to run the suite of tests and determine which ones fail

Mmusij: Created page with "Category:Agile:ArticlesCategory:Agile:XPCategory:Agile Behaviour Driven Development or BDD is a technique used to gain technical and functional feedback using wri..."

2019-01-21T05:51:25Z

Created page with "Category:Agile:Articles Category:Agile:XP Category:Agile Behaviour Driven Development or BDD is a technique used to gain technical and functional feedback using wri..."

New page

[[Category:Agile:Articles]][[Category:Agile:XP]][[Category:Agile]]

Behaviour Driven Development or BDD is a technique used to gain technical and functional feedback using written feature definition to generate step definitions that in turn execute unit tests, such as those that are used with [[Test Driven Development (TDD)]] via a test agent.

The approach closes the feedback loop from functional requirements to technical unit tests and provides a functional context for the unit tests.

==Behaviour Driven Development Cycle==

[[File:Behaviour_Driven_Development_(BDD).jpg|500px|Behaviour Driven Development (BDD)]]

# The cycle of BDD starts with writing a feature definition or testable spec using the [[Gherkin Format]]
unit test that encapsulates the expected behaviour, sunny day and rainy day, to be satisfied by the intended code construct.
# The next step is to run the suite of tests and determine which ones fail
# If a test fails then write some code to resolve the test failure. N.B. If a rainy day test receives an expected exception, then this is a pass, in that, this is expected behaviour. # If it received a different exception or no exception at all, then this would be deviating away from the expected behaviour stated in the unit test, and hence, would be a failed test.
# Next run the tests again to ensure that the test suite passes
# Refactor any code that needs refactoring. N.B. If code is duplicated in more than one area then this may suggest that the code should be refactored. The eradication of technical debt and evolution towards an elegant design may also influence refactoring efforts. Unit tests can also be refactored for improved maintainability.
# Goto the first step. N.B. Many small TDD cycles tend to work best especially when incorporating refactoring efforts rather than writing a bulk of tests, then writing a bulk of code and then having to fix a bulk of failed tests.

==Benefits==
* Refactoring and enhancing code with full suites of unit tests can be done quickly as running the unit tests provides immediate feedback as to whether there are any issues
* Other forms of testing such as functional testing and integration testing benefit from code that has been hardened with unit tests
* Development efforts tend to be more focussed to satisfy the expected behaviour in tests rather than over developing code
* If refatoring is incorporated well during the TDD cycles the code design grows in an elegant form that meets the expected behaviour rather than introducing assumptions, which may later be realised as constraints.
* A suite of passed tests provides a very good level of confidence in the team that their code works

==Challenges==
* Time taken to write tests can be exhaustive when compared to new code development time and may be very tempting to skip tests and just write code.
* New testing skills may need to be introduced to developers, as they are now tasked with providing enough test coverage of their code. Boundary value analysis for example, may be a new skill to be acquired by the developers to ensure that they have sufficient test coverage.
* The number of rainy day unit tests when compared to the number of sunny tests has been quoted as being as much as 10 rainy day to 1 sunny day, which may be a new discipline for developers.
* For extensive suites of unit tests, these may be overwhelming to maintain and keep current. Hence, refactoring tests may be just as important as refactoring code.

==See Also==
* [[Extreme Programming (XP)]]
* [[Test Driven Development (TDD)]]

==References==
# Test Driven Development: By Example, Kent Beck, 2001
# Extreme Programming Explained, Kent Beck and Cynthia Andres, 2004

← Older revision		Revision as of 23:54, 30 April 2020
Line 39:		Line 39:
	* [[Extreme Programming (XP)]]		* [[Extreme Programming (XP)]]
	* [[Test Driven Development (TDD)]]		* [[Test Driven Development (TDD)]]
			* [[Coding Dojo]]

	==References==		==References==