This is good advice, but OTOH, I do think it's going about things the wrong way to a certain extent.
Testing your site with certain strings isn't a complete way to determine if it's safe or not. You should "prove" to yourself it's safe against all attacks. Not just the ones you know about.
Definitely worth trying the "problem" strings as a simple sanity check though.
It's clear from the source that a) is vulnerable, whilst b) is not. I think programmers just need to be trained to have massive alarm bells go off in their head when they see some external string used in the output/markup in an unsafe way.
My point is exactly yours, but with added testing:
* Do the Right Engineering(TM) to guarantee no XSS
* Followed by having someone else confirm your certainty.
If you only do the first step, I'm nearly certain your site will eventually be vulnerable simply because we're all human and it's so easy to make mistakes in user input handling.
Otherwise you can wait until someone else proves that you missed something (using similar easy tests). Maybe they'll be nice people who will tell you about it. Maybe they'll be mean and will make you look like a fool publicly. Or maybe they'll be evil and exploit your users without you ever finding out.
Testing your site with certain strings isn't a complete way to determine if it's safe or not. You should "prove" to yourself it's safe against all attacks. Not just the ones you know about.
Definitely worth trying the "problem" strings as a simple sanity check though.
For example js code:
a). myNode.innerHTML = someUserInput;
b). myNode.appendChild(document.createTextNode(someUserInput));
It's clear from the source that a) is vulnerable, whilst b) is not. I think programmers just need to be trained to have massive alarm bells go off in their head when they see some external string used in the output/markup in an unsafe way.