It is not required for this algorithm, it says so in the footnote
"Note: This kata uses the non-padding version ("=" is not added to the end)."

Well, probably not judging by the satisfaction rating ;-)

null == undefined, so it works. :/

The whole ignoreTags thing has so many problems I'm going to leave it at

• specify it in the description,
• leave it to solver to implement it,
• and then f*rking TEST IT.

Won't happen in a four year old kata of course. :P ( Preventing accidental approvals again? )

ignoreTags is never tested, nor nested tags.

Also, needs random tests.

The initial code is wrong: ignoreTags are passed in as undefined if it's absent, not null.

This solution is really tiny but is wrong. There is no padding management

Test.assertEquals("z".toBase64(), new Buffer("z").toString('base64')) // INVALID egAA not equals eg==

You return egAA but the correct value is: eg== you are not managing the pad element `='

ignoredTags is always undefined.
No test cases for inserted BBCodes

Error with provided test cases:

ReferenceError: compare is not defined

The error messages could use some work. I'm getting something like:
<s>Hello, World!</s>
but got
Hello,
World!

...but it's really unclear what the problem is. As far as I can see, I'm giving the correct code, but the tests says not. If you could JSON.stringify the "expected" and "got" code, it would be much easier to see what the difference is.

As long as you define the function within the test code, you'll be OK. This ensures that it is set last.

I used your compare function, although I wonder if user will be able to redefine it to always pass and break the test cases.

No need to feel stupid! This is a good Kata, it just needs refinement.

Thanks for great feedback. I feel so stupid right now.

One more thing: you need to specify that [img] tags that don't start with http shouldn't be parsed.

However, I think this is actually an incorrect limitation, since you can have a valid URL that starts with the "relative protocol" (//) or relative links with no protocol at all.

A couple of issues that would make this a much nicer kata:

• In your example tests, you forgot the closing </s>, which fails when it shouldn't
• There actually is no [link] bbcode, it's always been [url], and is [url] on the wiki article. This is confusing, and effectively wrong.
• You link to to polish Wikipedia. Not a serious issue, but confusing.
• I really don't feel that simply linking to the Wiki article is good enough in a kata. It would be really easy to include examples of the various inputs and outputs in your description. Try to write a complete spec, as if there were no outside information available to the solver.
• While I appreciate the tests, you really will need to provide custom tests to encode the HTML characters in the expected and actual strings, and present them to the solver. Right now, there's basically no way to see where the errors occur, because the formatting is being rendered by the browser.

You use something like the following to handle the last case:

function encode(html) {
  return '<pre>' +
      html
        .replace(/&/g,'&')
        .replace(/</g,'<')
        .replace(/>/g,'>')
      + '</pre>';
}
function compare(input, expected) {
  var actual = parseBBCode(input);
  Test.expect(actual===expected,
      'Expected '+encode(expected)+' but got '+enocde(actual));
}

// use like this
describe('Basic BBCode', function() {
  it('should handle bold', function() {
    compare('[b]hi[/b]', '<b>hi</b>');
  });
});

The reason this is important is, right now, I'm getting this error:

Test Failed: Expected: <script>alert("Whoops")</script>, instead got: <script>alert("Whoops")</script>

As you can see, that's not very helpful — I can't even tell if the issue is on my end or yours.