Test Driven Development #3
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Nice effort! Looking forward to your thoughts on this one. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I'm going to start chipping away at this PR over the next week but comments/contributions are welcome. In my opinion TDD (or some offshoot/variation) is an incredibly important, necessary and powerful tool not just for protection against regressions but also for velocity in the initial implementations if done properly, refactoring ability and for turnaround time for hotfixes (regression specs are much easier to write in the context of a rich and comprehensive test suite).
Despite my efforts to evangelize this over the years we haven't really internalized it at Lockstep—I still regularly see PRs even on greenfield projects that have no specs or specs that were clearly added after the fact. Even low-hanging regression specs are frequently omitted. But the best firms in our industry stand by this as a cornerstone of their engineering practices (Pivotal, Thoughbot, etc), and it has been an important driver of stability/productivity/velocity for my own work over the years.
I'd like to begin the process of becoming more serious and formal about this as part of our development practice, but I also want to standardize our philosophy and approach because there are many ways to do XTDD poorly and I think they contribute to the failure of adoption. I'll be outlining my thoughts in this new playbook section.