Meh, the "YAGNI" citation by @dhh is pretty weak IMO. YAGNI is a guideline, a heuristic, not an absolute inviolable law of nature. And that's what experience buys you as a developer: the wisdom and insight to anticipate things that are likely to be needed, and places where code should be structured a certain way now, to accommodate future changes.
What we need is a new acronym (well, maybe somebody has probably already coined it, but whatever) YPNGTNI: You're Probably Not Going To Need It.
Wouldn't this potentially muddy up his tests though? Now he's creating a lot of mocks for a simple create action. Not only that, but should the create action not be called "create_and_maybe_send_to_social_networks"?
The CRUD metaphor doesn't map well to an application's network API -- which is what controllers/actions are, after all. Like if there's some code that gets executed when you click the "create comment" button, that's how you name it. Doesn't matter that the code creates a comment and maybe posts to social networks and some other things.
big picture tangent: if you've gained enough experience/wisdom to accurately predict needed features, you should encapsulate them in a product (or library/component/framework/plugin etc) to be sold/open sourced. In this way, you should never be able to anticipate things likely needed, unless you are writing such a product. :-) Not entirely facetious, as this process does actually happen as features get pushed down into standard libraries, languages, operating systems, hardware (e.g. video decoders). It's a similar idea to something attributed to Turing http://www.turing.org.uk/book/extracts/ext6-326.html:
There need be no real danger of it ever becoming a drudge, for any processes that
are quite mechanical may be turned over to the machine itself.