如何测试在其构造函数中对集合调用 fetch 的视图？答案

【问题标题】：how to test a view that calls fetch on a collection in its constructor?如何测试在其构造函数中对集合调用 fetch 的视图？
【发布时间】：2015-12-06 23:27:22
【问题描述】：

我有一个 BackboneView，我在创建时传递了一个集合

  var my_collection = new Collection();
  new MyView({temp: template, collection: my_collection });

在视图内部，像这样在构造函数中对集合调用 fetch() 方法

export class MyView extends Backbone.View {

    constructor(options){

      this.collection = options.collection;
      super();
      this.collection.fetch().done(function(resp){
      that.render();
      })
    }
    render(){
    }

}

我有（过去时）一系列测试，像这样测试视图的 UI/模板

  describe('testing my view', function() {
    it('should have one main child - div 6 ', function() {
      expect(myview.el.children.length).to.equal(1);
    });
  });

但是，由于我现在添加了将集合传递给视图的代码，并在构造函数中调用了集合上的 fetch 方法，所以我的所有测试都失败了，因为视图每次运行时都会尝试调用 fetch 方法测试。即使我传递了一个存根集合，我也必须设置一个url，并且视图将尝试获取存根集合，从而导致 404

 var gs = class StubCollection extends Backbone.Collection{

   constructor(options){
    this.url = '/blah';
   }
 }

  const drv =   new MyView({temp: template, collection: new gs()});

我需要在视图中的集合上调用 fetch（即我不能不使用该代码）。在这种情况下如何继续测试视图？

【问题讨论】：

标签： javascript backbone.js sinon chai karma-mocha

【解决方案1】：

您可以存根 fetch 方法本身。在StubCollection里面定义为：

function fetch() {
    return $.Deferred().resolve().promise();
}

根据Backbone's documentation，fetch返回一个jqXHR，代表发送的请求。

jqXHR 是一个 Promise，它是一个对象，代表一个正在进行的进程，可能成功或失败，并具有称为 done 和 fail 的方法，用于注册回调，以便分别在成功或失败时调用。（jqXHR请求成功则成功，失败则无法发送或服务器返回错误码）。

在上面的代码中，我们手动创建了一个Deferred object（用于创建promise），并立即将其状态更改为成功（使用resolve）。然后我们返回它的承诺。因为 promise 立即被认为是成功的，所以会立即调用 done 回调。

【讨论】：

非常感谢。您能否更新您的答案或添加评论以包含如何以类似方式模拟 Backbone.save() 的示例（我遇到了类似的问题）
@Leahcim 您可以存根模型的sync 方法（发出请求）以模拟服务器返回更改属性的哈希：function sync(method, model, options) { return $.Deferred().resolve(options.attrs || model.toJSON(options)).promise(); }

【解决方案2】：

不是最简单的解决方案，但从长远来看绝对是最好的： 您不应从视图中对集合调用 fetch。

视图实际上并没有告诉集合或模型该做什么。视图仅呈现数据和/或捕获用户输入。加载所述数据的调用应该在其他地方。根据您喜欢遵循的范例，这可能在控制器或命令中。这将使测试变得更加容易，因为您的视图将更加系统不可知，即他们对何时发生的事情知之甚少。视图、模型、集合和服务应该总是尽可能的愚蠢：它更容易测试、重用、扩展和修改。所有特定于应用程序的代码都应放入您的控制器和命令中。 IE。它们是将您与应用程序无关的视图、模型和服务结合到您正在处理的特定应用程序中的粘合剂。

【讨论】：