Quick Refresh : Introduction to Test-Driven development (TDD)
Introduction to Test-Driven development (TDD):
q Based on business requirements, first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally re-factor the new code to acceptable standards.
q Using TDD to produce code means that developers begin by setting out exactly what the code should do rather than beginning with how the code should satisfy the requirement.
q JUnit: Most of the projects which use Test-driven development (TDD) for Java development use JUnit to write test.
Improvement needed in TDD approach:
q Programmers Perspective - Programmers always wanted to know:
ü “Where to start” - Every Business Analyst (BA) has their own template for writing the Business Requirement document (BRD).
ü “What to test and what not to test” – Many a times all scenarios are not listed in BRD. No formal agreement/acceptance criteria between the Business Analyst (BA) and Developer.
ü “How much to test” at one time
ü “What to call” the tests
ü “How to understand why a test fails”
ü “How to report the result” – BA not able to understand JUnit test results.
q Business Analyst Perspective:
ü Business Analyst has less insight of what scenarios are implemented as part of the code.
ü Business Analyst has no report to look, which confirms that built product is as per requirements and all scenarios are covered.
Improving TDD with Behavior Driven Development:
Behavior Driven Development: It is an approach of Linking User Stories and Domain Driven Design to Testing
BDD helped us to minimize problems in TDD listed problems by providing-
q A formalised template for User Stories. This story file is written by Business Analyst and forms agreement/acceptance criteria between him and Developer.
q Able to create testable User Stories since they are defined in a formal manner and written in simple English.
q Best fit for the projects which follow Agile methodology.
q Scenarios can be grouped as per functionality rather than based on code component.
Comments
Post a Comment