Question

我有两段测试API端点的代码，我知道单元测试不会向服务器发出HTTP请求，因为我正在使用虚拟数据构建API服务（仅使用数组和其他数据结构来保存数据））。我想知道其中哪个是真正的单元测试（通过对什么是单元测试的真正定义）

我已经阅读了许多有关TDD和BDD的教程，并且我知道代码的第一个版本是验收测试，我的问题是，在许多教程中，这个第一个版本称为单元测试，但是有人说这是验收测试。。我有点困惑

// first version -- the one I believe to be acceptance test

it('should return a list of meetups that meets the search criteria', (done) => {
    agent
     .get('/api/v1/meetups/search')
     .query({ searchTerm: 'meetup 1' })
     .expect(200)
     .end((err, res) => {
         if (err) return done(err);
         res.body.status.should.equal(200);
         res.body.data.should.be.an('array');
         res.body.data.length.should.be.greaterThan(0);
         done();
     });
});

// second version -- using sinon to mock req and res object used in the route handler function

it('can search for meetups by topic', () => {
    const req = {
        query: {
            searchTerm: 'Sample Meetup'
        }
    };

    const res = {
          status() { },
          send() { }
    };

    res.status = sinon.stub(res, 'status').returns(res);
    res.send = sinon.stub(res, 'send').returns(res);

    myController.searchMeetups(req, res);
    res.status.firstCall.args[0].should.equal(200);
    res.send.firstCall.args[0].should.have.property('data');
    res.send.firstCall.args[0].data.length.should.be.greaterThan(0);
 });

对于两个版本的测试都有效，如果它是适用于API的单元测试，我想澄清一下API接受测试

Answer 1

意见：

第二种方法绝对是单元测试。

第一种方法更接近验收测试，尽管我更愿意将其称为功能测试。大概任何后端数据库等都仍然被模拟出来。

您没有问的问题是，哪种方法更适合测试REST API？我认为，明确答案是第一种方法。这为您提供了一系列测试，它们尽可能地模仿了实际API用户的体验，使您可以就每次测试返回的响应和标头值等做出简洁明了的声明。

保留用于各个模型方法的单元测试，对控制器方法进行功能测试。那是我的0.02美元。

Answer 2

欢迎您！

这里的确是一个验收测试。它也可能也可以作为集成测试。

在此测试中，您正在测试（很自然的猜测-我不知道您的服务到底做了什么，但希望您能理解这个想法）：

您的服务器正常运行的事实
可能一种或多种身份验证方法，用于验证用户是否具有请求此URI的所有必要权限
可能还有很多其他中间件，正确地准备了请求，格式化了数据等等。
也许与数据库来回一些
可能有一些用于日志记录，调试等的工具。
服务的核心功能（以正确的格式返回聚会的列表）

一个测试就包含很多东西！如果管理所有这些的数百行代码中只有一行（您写的一些，其他人写的）中只有一个错误，那么很多事情都会出错。最后，您唯一关心的是一个包含一些项目的数组，这是用户期望的功能，即accepts。这就是为什么我们称其为UAT（或用户接受测试）的原因。

您还可以说这是一次integration测试，因为您正在测试应用程序的不同部分：服务器和数据库。

您还可以听到有关E2E（端对端）测试的信息：例如，测试前端还正确显示从刚测试的后端检索到的所有聚会。还有许多其他类型的测试...

单元测试实际上是测试可以找到的最小可测试单元的代码。在您的方案中，在您的请求生命周期中有很多功能。给定参数X，函数Y总是返回Z吗？函数A，B，C，D ...怎么样？

否则输入：如果上述测试失败，您是否知道代码的哪一部分失败？如果您的代码中有2个问题，但是由于请求在第一个错误时失败，该怎么办呢？另外：您如何确保该部分永远不会再次失效？

笔试有点乏味，有很多方法可以正确完成。有时不可能（或非常困难）在没有任何其他依赖项的情况下测试一个功能（例如，调用数据库的功能），并且不能指望您对一个非常大的项目进行100％的测试。但是您应该在那儿争取一个“足够大”的数字。

有时在单元测试的代码之间的“胶水”中存在问题。完美的功能，竞争条件或...之间可能会出现网络问题，在这种情况下，您需要进行集成测试。

我需要根据单元测试的标准来说明其中哪些测试是100％单元测试

2 个答案: