
A case for writing unit tests for your blog posts - tosbourn
http://tosbourn.com/2013/12/other/case-writing-unit-tests-blog-posts/
======
robbiemitchell
If you want a handy outline for a persuasive blog post (or any other
communications medium), try the "Decker Grid".

 __*

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...](http://sendgrid.com/blog/principles-of-a-killer-hackathon-demo/)

~~~
tmarthal
Everything old is new again. The 'Five Paragraph Essay' is not a 'Decker
Grid', nor is it new.
[http://en.wikipedia.org/wiki/Five_paragraph_essay](http://en.wikipedia.org/wiki/Five_paragraph_essay)

~~~
robbiemitchell
I considered linking to that same page, but it seemed overkill.

------
lmm
I've had this experience. I've written a long, rambling post that I like, but
failed to include the final paragraph that makes explicit the point I
originally wanted to make. Or I've found myself with paragraphs that just
don't quite go together.

------
moron4hire
I used to be a big advocate for unit testing, but lately, I think they are
often a waste of time. They are great if you already know what you want to
make and want to make sure you get-it-right-the-first-time. But if you're
exploratory programming, designing as you go (which is one of the advertised
uses of TDD), then you're likely to end up with 4 times as much test code as
real code that all has to change drastically once you realize your initial
assumptions were wrong. At that point, it's often easier to just scrap it all
and start over than it is to figure out if the failed tests are because of
bugs in the code or mismatches between the newer code and older tests.

~~~
jdlshore
I agree that TDD isn't great if you're just exploring a problem domain. For
that, I use spike solutions (throw-away standalone programs).

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.

~~~
moron4hire
Yeah, the key is interface testing. I have a MUD that I'm writing right now
with which I fell into an overly verbose TDD trap recently.

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.

------
RougeFemme
Interesting.. .I had never considered the parallels between (technical)
writing and coding, but this is often what happens when I write. And I guess
this could be extended to include outlining vs. specs or pseudocode. . .for
those who write code and/or prose in a more structured process.

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.

------
andrewaylett
This is a good idea -- I can certainly say that I've written stuff that would
be improved by refactoring. Can I encourage people to write actual unit tests
for any code presented, too? I usually take my code snippets from a small
standalone project, with unit tests and a build script (Maven, as I usually
work in Java), placed in a git repository that I link to.

------
vijayr
Isn't this just a checklist? Something like (for a tutorial type post):

1\. Are the steps outlined clear enough?

2\. Are appropriate screenshots included?

3\. Are error messages explained?

etc etc?

------
krapp
I don't know that blog posts necessarily are (or should be) structured enough
to lend themselves to 'unit testing' in any way which makes that term
relevant. What OP is describing seems to be basically previewing the post
first before publishing it?

------
taeric
Any chance I can make a push for blog posts to all be literate programming? :)

~~~
girvo
You could almost turn it into rapGenius styled annotation of your own post -
comments and pseudo code read as a part of the post, inextricably linked, but
separate.

~~~
taeric
This is the first I've heard of rapGenius. Evidently I was under a rock.

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.

------
Eyas
What is described sounds closer to a spec than unit tests, correct? This is
probably a great idea for a lot of prose in general, not just blog posts.

