node.js에서 데이터베이스를 조롱합니까?

node.js에서 데이터베이스를 조롱합니까?

---

이 경우 mongodb블로그 REST API의 백엔드로 사용하는 node.js 애플리케이션의 데이터베이스를 어떻게 모의 처리 할 수 있습니까?

물론 데이터베이스를 특정 데이터베이스로 설정할 수는 testing있지만 여전히 데이터를 저장하고 코드 만 테스트하지 않고 데이터베이스도 테스트하므로 실제로 단위 테스트가 아니라 통합 테스트를 수행하고 있습니다.
그래서 어떻게해야합니까? 응용 프로그램과 db 사이의 중간 계층으로 데이터베이스 래퍼를 만들고 테스트 할 때 DAL을 교체 하시겠습니까?

// app.js  
var express = require('express');
    app = express(),
    mongo = require('mongoskin'),
    db = mongo.db('localhost:27017/test?auto_reconnect');

app.get('/posts/:slug', function(req, res){
    db.collection('posts').findOne({slug: req.params.slug}, function (err, post) {
        res.send(JSON.stringify(post), 200);
    });
});

app.listen(3000);

---

// test.js
r = require('requestah')(3000);
describe("Does some testing", function() {

  it("Fetches a blogpost by slug", function(done) {
    r.get("/posts/aslug", function(res) {
      expect(res.statusCode).to.equal(200);
      expect(JSON.parse(res.body)["title"]).to.not.equal(null);
      return done();
    });

  });
));

---

데이터베이스 소프트웨어로 테스트하지 않고는 데이터베이스 관련 코드를 제대로 테스트 할 수 없다고 생각합니다. 테스트중인 코드가 자바 스크립트뿐만 아니라 데이터베이스 쿼리 문자열이기 때문입니다. 귀하의 경우 쿼리가 단순 해 보이지만 영원히 그렇게 믿을 수는 없습니다.

따라서 모든 데이터베이스 에뮬레이션 계층은 반드시 전체 데이터베이스를 구현합니다 (아마도 디스크 스토리지 제외). 그러면 단위 테스트라고 부르더라도 데이터베이스 에뮬레이터와 통합 테스트를 수행하게됩니다. 또 다른 단점은 데이터베이스 에뮬레이터가 데이터베이스와 비교하여 다른 버그 세트를 가질 수 있으며 결국 데이터베이스 에뮬레이터와 데이터베이스 모두에 대해 코딩해야 할 수 있다는 것입니다 (IE, Firefox, Chrome의 상황과 유사합니다. ).

따라서 제 생각에는 코드를 올바르게 테스트하는 유일한 방법은 실제 데이터베이스와 인터페이스하는 것입니다.

---

조롱에 관한 일반적인 경험 법칙이 있습니다.

소유하지 않은 것을 조롱하지 마십시오.

db를 모의하려면 추상화 된 서비스 계층을 숨기고 해당 계층을 모의하십시오. 그런 다음 실제 서비스 계층을 통합 테스트해야합니다.

개인적으로 나는 테스트를 위해 모의를 사용하지 않고이를 위에서 아래로 디자인하는 데 사용하여 이동하면서 서비스 계층을 모의하고 결국에는 이러한 계층을 구현하고 통합 테스트를 작성하는 데 도움이됩니다. 테스트 도구로 사용하면 테스트를 매우 취약하게 만드는 경향이 있으며 최악의 경우 실제 동작과 모의 동작 사이에 차이가 발생합니다.

---

지금까지 선택한 답변이나 다른 답변에 동의하지 않습니다.

QA에 들어가기 전에 혼란스럽고 DB 스키마와 코드에 대한 복잡한 변경으로 인해 발생한 오류를 포착 할 수 있다면 멋지지 않을까요? 나는 대다수가 예라고 외칠 것이라고 장담한다!

가장 확실하게 DB 스키마를 격리하고 테스트해야합니다. 그리고 에뮬레이터 나 무거운 이미지 또는 DB와 머신의 재현을 기반으로하지 않습니다. 이것이 바로 SQLite와 같은 것입니다. 실행중인 메모리 내 경량 인스턴스와 메모리 인스턴스에서 변경되지 않는 정적 데이터를 기반으로 모의 작업을 수행합니다. 즉, 실제로 DB를 격리하여 테스트하고 테스트를 신뢰할 수 있음을 의미합니다. 그리고 분명히 그것은 메모리, 뼈대에 있기 때문에 빠르며 테스트 실행이 끝날 때 폐기됩니다.

그렇기 때문에 사용중인 DB 엔진 / 런타임의 매우 가벼운 메모리 인스턴스로 내 보내진 SCHEMA를 테스트해야하며, 매우 적은 양의 정적 데이터를 추가하면 격리 된 모의 DB가됩니다.

정기적으로 (자동화 된 방식으로) 실제 DB에서 실제 스키마를 내보내고 QA에 푸시 할 때마다 라이트 인 메모리 DB 인스턴스로 가져 오기 / 업데이트하면 DB 관리자 또는 다른 사용자가 최신 DB 변경 사항을 즉시 알 수 있습니다. 최근에 스키마를 변경 한 개발자는 테스트를 위반했습니다.

최선을 다해 답변 해주신 것에 박수를 보내는 동안 할 수 있다면 현재 답변에 반대표를 던지 겠지만 저는 새롭고 아직 그렇게 할 수있을만큼 충분한 평판을 얻지 못했습니다.

"당신이 소유하지 않은 것을 조롱하지 마십시오"라고 답한 사람에 관해서. 나는 그가 "당신이 소유하지 않은 것을 시험하지 마십시오"라고 말하고자했던 것 같습니다. 그러나 당신은 당신이 소유하지 않은 것을 조롱합니다! 왜냐하면 그것들은 격리 될 필요가있는 테스트 대상이 아니기 때문입니다!

I plan on sharing the HOW with you and will update this post in a future point in time with real example JS code!

This is what many test driven teams do all the time. You just have to understand the how.

---

My preferred approach to unit test DB code in any language is to access Mongo through a Repository abstraction (there's an example here http://iainjmitchell.com/blog/?p=884). Implementations will vary in terms of DB specific functionality exposed but by removing all the Mongo code from your own logic you're in a position to Unit Test. Simply replace the Mongo Repository implementation with a stubbed out version which is trivially easy. For instance, just store objects in a simple in-memory dictionary collection.

You'll get the benefits of unit testing your own code this way without DB dependencies but you'll still need to do integration tests against the main DB because you'll probably never be able to emulate the idiosyncrasies of the real database as others have said here. The kind of things I've found are as simple as indexing in safe mode vs without safe mode. Specifically, if you have a unique index your dummy memory implementation might honour that in all cases, but Mongo won't without safe-mode.

So whilst you'll still need to test against the DB for some operations, you'll certainly be able to unit test your own logic properly with a stubbed out Repository implementation.

---

The purpose of mocking is to skip the complexity and unit test own code. If you want to write e2e tests then use the db.

Writing code to setup/teardown a testing DB for unit testing is technical debt and incredibly unsatisfying.

There are mock libraries in npm:

mongo - https://www.npmjs.com/package/mongomock

mongoose - https://www.npmjs.com/package/mockgoose

If those don't support the features you need, then yes you may need to use the real thing.

---

I had this dilemma and chosen to work with a test DB and clean it every time the test begins. (how to drop everything: https://stackoverflow.com/a/25639377/378594)

With NPM you can even make a test script that creates the db file and cleans it up after.

참고URL : https://stackoverflow.com/questions/12526160/mocking-database-in-node-js