Question

我有一个类可以加载图像，关闭它或重命名它（至少现在，将来会有更多的打开文件操作）。

我用Facade模式实现了它（我想是这样）。

当我尝试为它编写测试时，我很快发现我需要使用不同的前提条件对其进行测试（例如，在调用某些方法之前加载图像时）。测试数量巨大，并且在添加新操作时会非常快速地增长。据我所知，这些不是单元测试，而是端到端测试。

我是TDD的新手，所以有人能告诉我，进行如此复杂的测试是正常的做法吗？

我期待得到关于我班级过多责任的答案，但我们可以考虑其他选择：

// pseudo-code

// #1 - my way
function onRenameButtonClick(newName) {
  imageFacade.rename(newName)
}

// #2 - the other way
function onRenameButtonClick(newName) {
  if (imageController.isOpened()) {
    imageRenamer.rename(imageController.image, newName)
  }
}

最后，我仍然需要测试＃2的正确行为，它仍然会涉及使用不同的前提条件。

你如何处理此类案件？这是正常的还是我做错了什么？

P上。 S.这里是我的门面类的骨架，注意在config中有纯函数，它们可以实际工作，而actions正在拼接这些纯函数并根据状态触发事件。

function makeImageWTF(loader, renamer) {
  return {
    state: {
      image: null,
      filePath: null,
      isLoading: false
    },
    config: {
      loader,
      renamer
    },
    triggers: {
      opening: new Bus(),
      opened: new Bus(),
      closed: new Bus(),
      renamed: new Bus(),
      error: new Bus()
    },
    actions: {
      open: function(path) {},
      close: function() {},
      rename: function(newName) {}
    }
  }
}

这是测试的骨架

describe('ImageWTF', function() {
  describe('initial state', function() {
    it('should be that', function() {
      var wtf = makeImageWTF()
      assert.deepEqual({
        image: null,
        filePath: null,
        isLoading: false,
      }, wtf.state)
    })
  })

  describe('#open(path)', function() {
    it('sets isLoading')
    it('calls config.loader with path')
    it('sets image, fileName')
    it('triggers loading, loaded or error')
    it('clears isLoading')
  })

  describe('#close()', function() {
    describe('when image is opened', function() {
      it('resets image')
      it('triggers closed')
    })

    describe('when image is NOT opened', function() {
      it('triggers error')
    })    
  })

  describe('#rename()', function() {
    describe('when image is opened', function() {
      it('calls config.renamer with oldName and newName')
      it('sets fileName')
      it('triggers renamed')
    })

    describe('when image is NOT opened', function() {
      it('triggers error')
    })
  })
})

Answer 1

（单位）测试就像生产代码一样 - 它们会变得复杂。但当然，目标应该是让它们尽可能简单。

如果您还没有对代码进行测试，我建议您开始编写测试以涵盖最重要的用例。一旦你有了工作，你可以重构它们。但对我来说，主要的重点是进行测试，你会从那条路上学到很多东西。

如果他们不是＆＃34;单元测试＆＃34;我不会太在意。从一开始，将它们更改为适合您的应用程序。

尽量不要将测试与生产代码相结合，因为您希望能够灵活地重构生产代码而无需同时更改测试（当然，反过来）。对我来说，单元测试的目的是让改变和重构代码变得简单快捷。它们不会捕获您应用程序中的所有错误或行为 - 因此您还需要关注其他类型的测试。

测试有状态的类

1 个答案: