Test Driven Development is just checklists
So, you’ve heard about Test Driven Development. Might’ve even read some blog posts about it. Almost certainly, you’ve heard DHH’s views on it. It sounds arduous, ceremonial, and more than a little intimidating.
Nah. It just sounds like that because most things proclaimed from on high do.
Test Driven Development is more of a methodology of how to build Todo lists based on your tests. I usually start pretty plain:
From here, I have a pretty clear idea of how to approach the issue. But what if I don’t know how to accomplish one of these things? How do I TDD it?
You don’t, yet. That’s what `rails c` is for.
The amount of time I spend in an interpreter these days is pretty close to 50/50. Interpreters let you test ideas quickly, figure out what you know and don’t know, and are the first way to seeing just how untenable a solution you’re cooking up is.
Only once you know what you’re trying to accomplish, do you jump back into TDD. Which you’ll then find, is the second(and best) way to seeing just how untenable a solution you’ve got is(and soon, how great it is)
So from there, you’re noticing commonalities between tests. Lets add contexts since we’re repeating them a lot:
Now we’re establishing quickly what our setup values are. See, every test(or set of tests) should be written with three parts:
1. Setup
2. The action/thing being tested(often ‘subject’), sometimes just the core being tested
3. Assertions/Expectations
Splitting your tests up into these parts is how you keep clarity to your tests.
Lets give it a quick try. And don’t get caught up on the factories- I’ve covered the fancy part of factory logic here.
That’s thorough, well-tested code for that method, that even helps to explain how you approach your authorization system. Tests are at their best when acting as another form of documentation.
What I’d recommend from the beginning, is asking some of the more experienced developers(or me!) around you for recommendations of similar tests to what you’re writing for you to emulate, when it comes to actually writing them. Even ask them to pair with you on testing! You’ll learn faster, and they’ll get more experience teaching(which anyone who does it often will explain, often teaches you a lot too).
