A case for writing unit tests for your blog posts
tosbourn.com
tosbourn.com
*
1. Opening: SHARP (a "hook" to catch reader's attention), your point of view, general action step (what you're asking them to do), and what the benefit will be.
2. Main body (1): Key point, sub-point 1, sub-point 2, sub-point 3
3. Main body (2): repeat
4. Main body (3) repeat
5. Closing: restate your point of view, suggest a more specific action step, restate the benefit, and end with another SHARP (memorable hook).
*
SendGrid's Elmer Thomas published a comprehensive write-up of the Decker communications training, including the grid, here: http://sendgrid.com/blog/principles-of-a-killer-hackathon-de...
But I've also noticed that a lot of people seem to use a very verbose, mock-centric approach to TDD. That approach isn't amenable to refactoring because anything more substantial than "rename" or "extract method" changes details that the tests depends on. If you're finding it difficult to change your code once it has tests, it might have something to do with the way you're writing your tests.
Originally, I had a script that ran an AI character through a number of actions executed via the same series of commands that a user would use, then checked the results also through the same series of commands that a user would use, and that worked great. But then I started down this road of thinking, "I never even had my own code! Look at me, granny coding, not unit testing like I should." And started down this boondoggle path of writing a few kilolines of test code.
Long story short, most of what I ended up writing was completely useless. The most important feature of testing is coverage, to have a way to hit every corner of the code to validate that it's all still "not failing", NOT to verify that the design is behaving lock-step as planned. Which is very important in this case because the game is being written in JavaScript, thus there is no static compile-time checking.
And I guess some steps could/would apply to some "non-technical" writing, as well. And it's what good (in my opinion) good English teachers do, too. Thinking back to one of my favorite high school teachers (who happened to teach English) and my (college) freshman English composition instructor.
1. Are the steps outlined clear enough?
2. Are appropriate screenshots included?
3. Are error messages explained?
etc etc?
That is impressive, but I don't care for how "click heavy" it is. More simply put, one of the things I like most about literate programming is how it rearranges the code to be more narrative based for the reader, less structure based for the computer. Sometime these align, but often I've found that my biggest mistakes are when I make structure compromises to try and preserve some sort of narrative coherence. Something I don't necessarily have to do for literate programming.