Thursday, May 28, 2015
TDD - Test-Driven Design
TDD, TFD, BDD, ATDD...all of those should be read x-y Design and not x-y Development. It would clarify the real value in doing development this way. However, it may seem if this is true, then the only tests that really matter are the BDD and ATDD tests. This would violate the testing pyramid where most tests should be Unit Tests. All systems do one thing, respond to input in some way. The response usually results in some state change and/or some other actions that also result in a state change. Example: User completes some task, task should be marked complete. Upon completion a communication should be sent to various recipients. That example contains so many assumptions that when one begins to design the feature, it would be impossible because the design is not yet specified. Enter BDD. First step is to set up the pre-conditions: User has a task that is in state InProgress. User completed form. Form passed validation. There are subscribers to the completion event. The subscribers are listed as follows: Josepha in accounting via email firstname.lastname@example.org The Budgeting Dept via some other application Etc etc etc. Next is to describe the action that causes a change. User marks task complete. Last is to verify the result. Task status is complete. Email sent. Budget app data sent. Etc etc etc In this way the requirements are not ambiguous and all the scenarios are easier to understand. We have a better starting point to design our system.