-
@saltnburnem Yeah but that's kind of the point. No one cares what the code is going to look like. Users definitely don't care about it. They care if features work a certain way. With TDD you think about what the thing you're testing will do for the caller, not about how the code will look.On twitter.com
❤️ 3 Favorites
Mood +7 🙂
-
@saltnburnem So you write a test that "this thing will not allow blank spaces." Then you make the test pass... And then you decide how you want the code to look, using the test to give you feedback on whether you broke it.Permalink On twitter.com
Mood -1 🙁
-
@saltnburnem It's really about tightening your feedback loop. You have a feedback loop for every line you write - maybe it's write code, try it out in the browser, and repeat. TDD tightens that up for you, so you don't need to fire up the browser to test out the line you wrote.Permalink On twitter.com
♻️ 2 Retweets
❤️ 1 Favorite
Mood -2 🙁
-
@saltnburnem Also, to @dan_abramov's original point, IT IS OKAY when TDD doesn't fit the problem you're working on. It's a tool - use it when it works, set it aside when it doesn't.Permalink On twitter.com
♻️ 1 Retweets
Mood -3 🙁
-
@saltnburnem @dan_abramov But, it's also okay to "just write code to see how it's going to work" (explore), then start over using tests to drive you towards what you learned while exploring. No pragmatic TDD practitioner will fault you for that - it's not cheating. We do it too!Permalink On twitter.com
Mood +2 🙂
-
@saltnburnem @dan_abramov And finally, it takes a long time to figure out how to use this tool effectively with your personal workflow. And that's okay! I think it's a tool worth learning, for the massive boost to your feedback loop. Using it 100% of the time is not the goal, nor is it realistic.Permalink On twitter.com
Mood +5 🙂
-
@saltnburnem @dan_abramov Lastly - if you ever want to pair some time, to see how it can be helpful, and maybe help it make sense - let me know! I'd love to do that. 😘Permalink On twitter.com
❤️ 3 Favorites
Mood +11 🙂