我应该模拟单元测试中的每个依赖项吗？

Question

经过大量阅读后，我发现人们建议在单元测试下模拟方法中的每个依赖项。

单元测试时我应该模拟所有依赖项吗？

我什么时候应该嘲笑？

但是，我有一个方法可以创建对象列表（依赖项）并使用这些对象的方法来更改列表。在现实场景中，该方法是将客户端发送的数据有效负载转换为这些对象。下面是 Typescript 中的代码实现，但它只是给你一个想法。

import {expect} from 'chai';

import 'mocha';

class Bar {
    private val: number;

    constructor(val: number) {
        this.val = val;
    }

    isValid(): boolean {
        return this.val !== 2;
    }

    canMergeWith(bar: Bar): boolean {
        return this.val === bar.val;
    }
}

class BarBuilder {
    constructor() {
    }

    createBars(payload: number[]): Bar[] {
        const bars: Bar[] = [];
        payload.forEach(p => {
            bars.push(new Bar(p));
        });

        const filtered = this.filterBars(bars);
        const merged = this.mergeBars(filtered);
        return merged;
    }

    private filterBars(bars: Bar[]): Bar[] {
        return bars.filter(b => b.isValid());
    }

    private mergeBars(bars: Bar[]): Bar[] {
        const merged: Bar[] = [];
        bars.forEach((bar, i) => {
            if (i > 0) {
                const before = bars[i - 1];
                if (!bar.canMergeWith(before)) {
                    merged.push(bar);
                }
            } else {
                merged.push(bar);
            }
        });
        return merged;
    }
}

describe('BarBuilder', () => {
    it('Should convert payload into valid bars', () => {
        const payload = [1, 2, 3, 4, 4, 5, 5];
        const barBuilder = new BarBuilder();
        const bars = barBuilder.createBars(payload);
        expect(bars).to.deep.equal([{val: 1}, {val: 3}, {val: 4}, {val: 5}]);
    });
});

目前，测试已通过。但这违反了我应该模拟类中每个依赖项的规则。

我的问题是我应该执行以下哪一项操作：

1. 为了遵守这条规则，我真的应该嘲笑 Bar 类吗？

如果是这样，我发现这样做还有另一个困难。如果我模拟 Bar 类，如何制作模拟方法canMergeWith并isValid 根据输入返回 true 或 false？这不就相当于重写了类本身吗？

2. 我应该重构我的代码吗？

我还想问题可能是我的代码不可测试。之前，方法canMergeWith和isValid属于BarBuilder. 为了可读性，我将它们移到了 Bar 中。但现在，单元测试BarBuilder不再是琐碎的事情。

3. 尽管事实上它违反了单元测试规则，但仍保留测试原样。

Answer 1

我发现人们建议在单元测试下模拟方法中的每个依赖项。

有些人建议这样做，是的。在链接的帖子中，更多的人不同意。单元测试实际上是一个有分歧的主题。

当我第一次得知没有整个行业广泛接受的单元测试定义时，我感到很惊讶。人们经常谈论单元测试，好像有一个定义，尤其是“模拟一切”定义；但如果您仔细阅读链接的线程，您会发现该方法存在许多缺陷，尤其是这些测试的脆弱性。

我认为“模拟一切”的定义仍然如此普遍，因为它是多么微不足道。没有任何思考，只是嘲笑一切。另一种方法是考虑何时进行模拟，何时不进行模拟。那更难了。你必须为嘲笑辩护。将单元测试定义为“模拟一切”更容易，因为这样您就不会考虑模拟的目的。这只是定义的一部分。

Ian Cooper发表了关于单元测试的演讲，单元测试由 Kent Beck 在 TDD 背景下定义。我发现他的观点比“模拟一切”的方法更现代。

Kent以非常具体的方式使用单元测试。当他使用这个短语时，他的意思是您应该能够将所有测试作为一个套件一起运行，而运行一个测试不会影响其他测试。隔离的单位是测试。由于人们认为隔离单元是被测试的类，因此犯了很多错误。它不是。

我的建议：当它们对你有帮助时创建模拟。不要创建模拟来满足规则。其背后不存在共识的规则。