- #99
- #98
- #97
- #96
- #95
- #94
- #93
- #92
- #91
- #90
- #89
- #88
- #87
- #86
- #85
- #84
- #83
- #82
- #81
- #80
- #79
- #78
- #77
- #76
- #75
- #74
- #73
- #72
- #71
- #70
- #69
- #68
- #67
- #66
- #65
- #64
- #63
- #62
- #61
- #60
- #59
- #58
- #57
- #56
- #55
- #54
- #53
- #52
- #51
- #50
- #49
- #48
- #47
- #46
- #45
- #44
- #43
- #42
- #41
- #40
- #39
- #38
- #37
- #36
- #35
- #34
- #33
- #32
- #31
- #30
- #29
- #28
- #27
- #26
- #25
- #24
- #23
- #22
- #21
- #20
- #19
- #18
- #17
- #16
- #15
- #14
- #13
- #12
- #11
- #10
- #9
- #8
- #7
- #6
- #5
- #4
- #3
Chatting About TDD Concepts with Friends
A snippet of a conversation with a friend: “If we switch to TDD for product requirements, it means all those tests we wrote are wasted.”
My thought is this: “Tests are a byproduct of TDD.”
Product behavior > Tests (automated documentation) > Practice (code). This means that when product behavior changes, the documentation will naturally change. The hassle of having to rewrite things comes from the fact that sometimes we don’t even have good documentation and just dive into coding.
Using TDD is simply a steady approach to simultaneously writing documentation and developing. Then BDD sees the value of tests as automated documentation, creating documents that both business and development sides can understand and maintain together.
- TDD - Test-driven development
- BDD - Behavior-driven development
- #2
- #1