When writing unit tests for an API wrapper, should I be making real calls to the REST API endpoints or should I use mocl responses that simulate successful and erroneous calls?
相关问题
- Angular RxJS mergeMap types
- Design RESTful service with multiple ids
- Axios OPTIONS instead of POST Request. Express Res
- Plain (non-HTML) error pages in REST api
- Dependencies while implementing Mocking in Junit4
相关文章
- C#使用http访问网络,有办法用指定网卡访问网络嘛?
- 我用scrapy写了一个蛮简单的爬虫怎么封装成一个api啊
- 后端给前端的API接口是怎么用代码写的
- How to replace file-access references for a module
- How to mock methods return object with deleted cop
- What is a good way of cleaning up after a unit tes
-
EF6 DbSet
returns null in Moq - Web Test recorder does not allow me to record a te
Unit tests mean testing only your unit (API wrapper), nothing else. Thus, unfortunately, you should mock the entire API.
On the other hand this never really gives me enough confidence, so I go for system tests (also known as component tests). In that case you should run your API wrapper against existing API, maybe embedded and started along with your test. In integration test, the ultimate scenario, you run your API wrapper against real, but most likely test instance of the API (sandbox, dev environment).
In well established area of database testing: unit tests mock entire DAO level, component tests run against in-memory database while integration tests connect to real database with some fake data.