Node.js approve library against other affirmative libraries

According to node.js assert library documentation :

The module is intended for internal use of node.js, but can be used in application code via require ('assert'). However, the statement is not and is not intended to be used as a general purpose library of claims.

I looked at Chai as an alternative assert library (there is no BDD API, only the assert API), and in the end I am assert that is very similar.

Why is the Chai assert library the best assert library? It does everything than node.js (besides just richer in terms of statement, but it's just syntactic sugar coating). Even simple things, such as the total number of statements made, are not available to both.

Did I miss something?

+5
source share
3 answers

UPDATE (April 2017): Node.js no longer warns people from using assert , so the answer below is deprecated. However, leave it for historical interest.

Here is the answer that I sent to a very similar question in the Node.js questionnaire .

https://github.com/nodejs/node/issues/4532 and other problems refer to the reason the documentation recommends not using assert for unit testing: there are errors of the edge case (or, at least, of course, surprises) and missing features.

A bit more context: knowing what we now know, if we built / built the Node.js core over and over again, the assert module would either not exist in Node.js or consist of fewer functions - maybe just assert() (which is currently an alias for assert.ok() ).

The reasons for this, at least from my point of view:

  • everything that is done in assert can be easily done in userland
  • the main efforts are better spent elsewhere than improving the unit testing module, which can be performed in the user area

There is an additional context here that others can add here or not (for example, why, all other things being equal, we would like to save a small kernel and do something in userland). But this is the so-called 30,000-foot look.

Since assert was in Node.js for a long time, and a lot of ecosystems depended on it, we are unlikely (at least as far as possible at this time) to ever delete assert.throws() and friends. That would break too many things. But we can discourage people from using assert and encourage them to use user interface modules that are supported by people who deeply care for them, who persistently fix bugs as a last resort, and which add interesting new features when it makes sense. So what is it all about.

True, if you make simple statements with simple cases, assert is likely to satisfy your needs. But if you ever outgrow assert , you will be better off with chai or something else. Therefore, we encourage people to start there. This is better for them (usually) and better for us (usually).

I hope this is helpful and answers your question.

+10
source

I assume that since no one has given me any good reviews, I will try to give some light to my original question after some time working with both node.js assert and chai assert.

The answer at the very end is that functionality is the same. The only reason chai is claimed is that if you read the code, you can better understand those tests, but more about that.

For example, testing for a null value with node.js:

assert (foo === null);

And using chai:

assert.isNull (Foo);

They are completely equivalent, and sticking to node.js assert limits your list of dependencies.

+4
source

Disclaimer: I am the author of the assertthat module, which I will refer to in this answer.

Basically, you can achieve all things with Node with a very own assert module, which you can do with all the other modules there, like Should.js , expect.js or assertthat . Their main difference is how you can express your intention.

Semantically speaking, the following lines of code are equivalent to each other:

 assert.areEqual(foo, bar); foo.should.be.equal(bar); expect(foo).to.be(bar); assert.that(foo).is.EqualTo(bar); 

There are two main differences syntactically:

First, the should syntax only works if foo not null or undefined , so it is inferior to others. Secondly, the difference in readability: although assert.that(...) is read as a natural language, everyone else does not.

After all, Chai is just a wrapper around several approval modules to make your life easier.

So, briefly edit the short story: No, there are no technical reasons why you should prefer each other, but readability and null compatibility may be the reasons.

Hope this helps :-)

PS: Of course, internally they can be implemented in different ways, so there can be subtle things, for example, how equality is checked. As stated in the disclaimer, I am the author of the claims, so I can be biased, but in the last few years I have had a situation from time to time, where it was argued that it was more reliable than others, but, as said, I can be biased.

+2
source

Source: https://habr.com/ru/post/1246496/


All Articles