4 ms·

Error messages. If the assertion framework knows what you're checking, it can provide a better message. E.g., "assert(a == 3)": "Assertion failed." vs. "asse

Error messages. If the assertion framework knows what you're checking, it can provide a better message. E.g., "assert(a == 3)": "Assertion failed." vs. "assertEquals(a, 3)": "Expected 3 but was X." The fancy "spec" style ("a.should.be.equal.to(3)") is overkill, though, I'd agree. It adds complexity for dubious benefit.

EGreg 13y ago
Why can't it be assert("a === 3", a, b) And then it can say "a === 3 failed. (2, 4)"
- dragonwriter 13y ago
  It can be, but both the test code and the error messages from that are worse than with many existing testing frameworks to my eye, so I wouldn't chose that over the existing alternatives.
  - EGreg 13y ago
    how are they worse? I don't want.to.sitThere.writingThis(kindOf, crap)
    - dragonwriter 13y ago
      > how are they worse? The code reads worse for a number of reasons: :: you've written an equality, rather than truth, assertion named "assert" rather than "assertEquals". :: you're writing what would be the code of a truth assertion as a string for the message test. For the same role, most unit testing frameworks have an equality assertion / expectation assertion that serves essentially the same role but reads better. > I don't want.to.sitThere.writingThis(kindOf, crap) Then don't use spec-style frameworks. There's plenty of xUnit and similar style frameworks that use simple assertions (and, yeah, you can just use bare truth assertions all the time if you want, but you've usually got a handful of nice tools for common cases like equality assertions to go with them.)
      - EGreg 13y ago
        Fine, how about this: function testCase() { // do some stuff assert(a>=b, 'less pictures than participants', a, b); // do some stuff assert(cool.length, 'cool is empty'); } output: "testCase: less pictures than participants (3, 4)" "testCase: cool is empty" easy, no?
        dragonwriter 13y ago
        If you want to write your own one-function test microframework on that model, feel free; I don't see any reason to prefer using it to existing frameworks, whether xUnit-style or spec-style.

EGreg 13y ago

Why can't it be assert("a === 3", a, b) And then it can say "a === 3 failed. (2, 4)"

dragonwriter 13y ago
It can be, but both the test code and the error messages from that are worse than with many existing testing frameworks to my eye, so I wouldn't chose that over the existing alternatives.
- EGreg 13y ago
  how are they worse? I don't want.to.sitThere.writingThis(kindOf, crap)
  - dragonwriter 13y ago
    > how are they worse? The code reads worse for a number of reasons: :: you've written an equality, rather than truth, assertion named "assert" rather than "assertEquals". :: you're writing what would be the code of a truth assertion as a string for the message test. For the same role, most unit testing frameworks have an equality assertion / expectation assertion that serves essentially the same role but reads better. > I don't want.to.sitThere.writingThis(kindOf, crap) Then don't use spec-style frameworks. There's plenty of xUnit and similar style frameworks that use simple assertions (and, yeah, you can just use bare truth assertions all the time if you want, but you've usually got a handful of nice tools for common cases like equality assertions to go with them.)
    - EGreg 13y ago
      Fine, how about this: function testCase() { // do some stuff assert(a>=b, 'less pictures than participants', a, b); // do some stuff assert(cool.length, 'cool is empty'); } output: "testCase: less pictures than participants (3, 4)" "testCase: cool is empty" easy, no?
      - dragonwriter 13y ago
        If you want to write your own one-function test microframework on that model, feel free; I don't see any reason to prefer using it to existing frameworks, whether xUnit-style or spec-style.