Am I implementing BDD correctly?
This is roughly what BDD should look like.  You're definitely on the right track in that you have a specific set of postconditions and expected results for every "public" method.  However, the tests for these postconditions are incomplete in some respects that I think will probably come up as edge conditions and/or browser quirks (assuming your system is going to run in a browser).  In addition, you're testing behaviors in this suite that are shared between your subclasses - even if they don't actually share a prototype, they do have a common interface and common expectations.

For incompleteness, I'm referring to 'should return false when value provided is null or undefined' when the corresponding test only tests null.  This should be two tests, one for null and another for undefined.  In addition, you should define and test the function's behavior for other values that are commonly mistaken for null and undefined, like 0, false, and ''.  The empty string is of particular importance because it's unclear from your tests whether an empty string is acceptable as long as it's specified - the source of your data might determine whether that's applicable.  I would go with two or three tests per native type: one that is acceptable, one that is not (if both are applicable), and one that is falsy (if the falsy value for the type is not already covered).  If you really want to go all out, define behavior for the parameters '0', 'false', 'undefined', and NaN.

This sounds like a pain to do - especially when you see that you need to define said behavior for all of the other functions whose preconditions are the same.  The root of the problem here is that your preconditions are not very DRY.  Each function has two test cases: null and 'asd' as inputs to test.  Since null and 'asd' are not really the only two inputs you can expect to get, your tests shouldn't be coupled to those two inputs.  Further, when you go to write your tests for your other rule subclasses, you will be unable to re-use your isErroneous and getError tests because they have specifically named null as erroneous and 'asd' as acceptable.

I'm not a mocha expert, so I don't know how helpful or cooperative it will be, but you can refactor your suites to test states rather than classes, and it will be far DRYer.  From what I can tell, the rule subclasses all have the following features:


A (theoretically unbounded) set of inputs to the test method that will:

return false
leave the object in an erroneous state

A (theoretically unbounded) set of inputs to the test method that will:

return true
leave the object in a validated state

An initial state before test is ever called, whose behavior remains unspecified.


Each of your subclasses has a different set of erroneous and valid inputs, but you can easily define the behavior of those three states independently:


A rule object in an erroneous state should:

return true from isErroneous()
return non-null from getError()
(become | not become) valid when a valid input is provided to test

A rule object in a validated state should:

return false from isErroneous()
return null from getError()
(become | not become) erroneous when an invalid input is provided to test

A rule object in its initial state should:

probably have defined behavior for getError and isErroneous, too.
become valid when a valid input is provided to test
become erroneous when an invalid input is provided to test



Now, your tests for all of your classes are reduced to the task of generating the input test cases and expected states they will generate.  For the RequiredRule, that could be easily expressed in two arrays; you might want something different for your more complicated rules, since the criteria are presumably individualized per object for those subclasses.  I might go with something like a generator.

The concept of a class is helpful for BDD when you have specific class invariants, but with javascript you are by no means limited to a one-to-one correspondence between a class (constructor/prototype) and its defined behaviors.  Like anything else in software design, you can tell your unit test is wrong as soon as you type the same thing 2 or 3 times.  Usually, you can fix the repetition by making the object of your suite (parameter to describe) something more applicable than the name of the constructor.