Node.js khẳng định thư viện so với thư viện khẳng định khác

Question

Theo Node.js khẳng định thư viện documentation:

Module này được thiết kế để sử dụng nội bộ Node.js, nhưng có thể được sử dụng trong mã ứng dụng thông qua yêu cầu ('khẳng định'). Tuy nhiên, khẳng định không phải là khung kiểm tra và không được sử dụng như một thư viện xác nhận chung chung.

Tôi đang xem Chai làm thư viện khẳng định thay thế (không có API BDD, chỉ API xác nhận) và cuối cùng tôi thấy chức năng xác nhận rất giống nhau.

Tại sao thư viện khẳng định của Chai là thư viện khẳng định tốt hơn? Nó làm tất cả mọi thứ hơn so với node.js (bên cạnh chỉ là giàu có về khẳng định có sẵn, nhưng đó chỉ là cú pháp đường phủ). Ngay cả những điều đơn giản như tổng số xác nhận được thực hiện không có sẵn trên cả hai.

Tôi có thiếu gì đó không?

Answer 1

CẬP NHẬT (tháng 4 năm 2017): Node.js không còn cảnh báo mọi người tránh xa việc sử dụng assert để câu trả lời dưới đây hiện đã lỗi thời. Tuy nhiên, để lại nó vì lợi ích lịch sử.

Đây là the answer I posted to a very similar question on the Node.js issue tracker.

https://github.com/nodejs/node/issues/4532 và các sự cố khác liên quan đến lý do tài liệu đề xuất chống lại việc sử dụng assert để kiểm tra đơn vị: Có lỗi trường hợp cạnh (hoặc ít nhất chắc chắn là bất ngờ) và thiếu tính năng.

Bối cảnh hơn một chút: Biết những gì chúng ta biết, nếu chúng ta thiết kế/xây dựng lõi Node.js trên một lần nữa, mô-đun assert sẽ không tồn tại trong Node.js hoặc khác bao gồm ít hàm hơn - khá có thể chỉ assert() (hiện là bí danh cho assert.ok()).

Những lý do cho điều này, ít nhất là từ quan điểm của tôi, là:

• tất cả những thứ được thực hiện trong assert có thể dễ dàng được thực hiện trong Userland
• nỗ lực cốt lõi được chi tiêu tốt hơn ở nơi khác hơn để hoàn thiện một kiểm tra đơn vị mô-đun có thể được thực hiện trong vùng đất người dùng

Có ngữ cảnh bổ sung mà người khác có thể chọn thêm tại đây hay không (chẳng hạn như tại sao, tất cả mọi thứ đều bình đẳng, chúng tôi sẽ ưu tiên giữ nội dung nhỏ và làm việc trong vùng người dùng). Nhưng đó là cái gọi là cái nhìn 30.000 foot.

Kể từ khi assert đã ở trong Node.js trong một thời gian dài và rất nhiều hệ sinh thái phụ thuộc vào nó, chúng tôi không chắc (ít nhất là tốt nhất có thể cho biết tại thời điểm hiện tại) để loại bỏ assert.throws() và bạn bè. Nó sẽ phá vỡ quá nhiều thứ. Nhưng chúng tôi có thể ngăn cản mọi người sử dụng assert và khuyến khích họ sử dụng mô-đun userland được duy trì bởi những người quan tâm sâu sắc về họ và những người tích cực sửa các lỗi cạnh và người thêm các tính năng mới thú vị khi có ý nghĩa. Vì vậy, đó là những gì đó là tất cả về.

Đúng, nếu bạn đang thực hiện xác nhận đơn giản với các trường hợp đơn giản, assert có thể sẽ đáp ứng nhu cầu của bạn. Nhưng nếu bạn đã từng vượt qua assert, bạn sẽ tốt hơn với chai hoặc bất kỳ thứ gì. Vì vậy, chúng tôi khuyến khích mọi người bắt đầu ở đó. Nó tốt hơn cho họ (thường) và tốt hơn cho chúng ta (thường).

Tôi hy vọng điều này hữu ích và trả lời câu hỏi của bạn.

Answer 2

Tôi đoán vì không ai cho tôi bất kỳ phản hồi tốt nào, tôi sẽ cố gắng cung cấp một số ánh sáng cho câu hỏi ban đầu của mình sau một thời gian làm việc với cả xác nhận node.js và xác nhận của chai.

Câu trả lời ở cuối cùng là chức năng khôn ngoan chúng giống nhau. Lý do duy nhất tại sao khẳng định của chai tồn tại là như vậy nếu bạn đọc mã, bạn có thể hiểu rõ hơn về các bài kiểm tra, nhưng đó là về nó.

Ví dụ, thử nghiệm cho một giá trị null với Node.js:

assert (foo === null);

Và sử dụng chai:

assert.isNull (foo);

Chúng hoàn toàn tương đương và gắn bó với node.js khẳng định giới hạn danh sách phụ thuộc của bạn.

Answer 3

Tuyên bố từ chối trách nhiệm: Tôi là tác giả của mô-đun assertthat mà tôi sẽ đề cập đến trong câu trả lời này.

Về cơ bản, bạn có thể đạt được tất cả những điều với assert mô-đun rất riêng Node rằng bạn có thể làm với tất cả các mô-đun khác trên mạng, chẳng hạn như Should.js, expect.js hoặc assertthat. Sự khác biệt chính của họ là cách bạn có thể thể hiện ý định của mình.

Ngữ nghĩa nói, các dòng mã sau đây đều là tương đương với nhau:

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

Cú pháp, có hai sự khác biệt lớn:

Thứ nhất, cú pháp should chỉ hoạt động nếu foo không bằng đến null hoặc undefined, do đó nó kém hơn so với những cái khác. Thứ hai, có một sự khác biệt về khả năng đọc: Trong khi assert.that(...) đọc như ngôn ngữ tự nhiên, tất cả những người khác thì không.

Sau khi tất cả, Chai chỉ là một wrapper xung quanh một vài mô-đun xác nhận để làm cho mọi việc dễ dàng hơn cho bạn.

Vì vậy, để cắt một câu chuyện dài ngắn: Không, không có lý do kỹ thuật nào để thích cái kia, nhưng khả năng đọc và khả năng tương thích null có thể là lý do.

Tôi hy vọng điều này sẽ giúp :-)

PS: Tất nhiên, trong nội bộ, họ có thể được thực hiện khác nhau, do đó có thể có những điều tinh tế ví dụ, bình đẳng được kiểm tra như thế nào.Như đã nói trong tuyên bố từ chối trách nhiệm, tôi là tác giả của assertthat vì vậy tôi có thể thiên vị, nhưng trong vài năm qua tôi đã có tình huống theo thời gian mà khẳng định là đáng tin cậy hơn những người khác, nhưng như đã nói, tôi có thể thiên vị.