-
Notifications
You must be signed in to change notification settings - Fork 5.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove TDD language from tutorial #6466
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These changes LGTM @guardrex
I'll now. Thanks again for all your contributions to docs! 🎆
Thanks for taking the feedback onboard, much appreciated. I have to say that I still don't quite understand why you write "It's important to make a new test fail once to confirm its testing logic is correct." It's like saying that it is important to write your code wrong and the write it correct. Why would I knowingly want to write wrong code? |
It helps to ensure that the logic of the test is sound. On a couple of occasions, this step worked to my advantage. I wrote a test that required some complex config/set up, wrote the assertion to fail, and 😮 the bleed'in thing PASSED! Orf! 😄 Upon further examination, I wrote some bad test logic that I needed to fix. This scenario hasn't played out often for me, but it has saved me a couple of times. There's no ironclad guarantee that this step will save a dev. However, it can help. |
Ah right, I get it. It's basically the same idea as when you do TDD, where you write your test before having finished the implementation of the code. In that case the test must fail. Then once you have implemented your code right, your test will pass. Sounds like your trick is useful when you've already implemented the code and doing the testing afterwards. |
Yes, that's right. Exactly so. |
Fixes #6464