ジャスミンユニットテスト：ロジックまたは実際の模擬データをテストすべきですか？

Question

単体テストを実行するときは、テストにハードコーディングが必要なリテラル結果をテストする方が良いですか（expect(x).toBe(mockedData.value)）

の論理をテストする方が良いでしょうか

私が期待しているリテラル結果を実際にテストしていると確信しているので、最初のアプローチは安全だと思われますが、2番目のアプローチはモックデータを心配するのではなくロジックをテストできるのでテスト自体を書き換えることなく後で変更することもできます）

いずれのアプローチの利点/欠点は何ですか？これらの場合のベストプラクティスは何ですか？続き

は簡単な例です：

// MockedData is a very long array of complex objects 
// each of them has a property 'value' of type number 
import mockedData from 'data.mock'; 

class ClassToTest { 
    private data; 
    constructor(data) { 
     this.data = data; 
    } 
    plusOne(): number { 
     return this.data.value + 1; 
    } 
} 

describe('test',() => { 
    let instance: ClassToTest; 
    beforeEach(() => { 
     instance = new ClassToTest(mockedData[0]); 
    }) 
    it('plusOne() should return the property "value" plus one',() => { 
     // Should I write this... 
     expect(instance.plusOne()).toBe(mockedData[0] + 1); 
     // ...or this? 
     expect(instance.plusOne()).toBe(17); // Because I know that mockedData[0].value is 16 
    }) 
}); 

はどうもありがとうございました!! :)

Answer 1

あなたのユニットでは、あなたのケースではplusOne()のロジック内のロジックがテストされます。だから、関数内で何かが変更されたかどうかだけを知りたければなりません。

誰かがあなたのロジックをreturn this.data.value + 2;に変更した場合、問題が関数ロジックまたはmockedDataにある場合にのみ、テストから離れないので、最も危険なパスはexpect(instance.plusOne()).toBe(17);です。

expect(instance.plusOne()).toBe(mockedData[0] + 1);を使用するのは、危険性の低いアプローチです。これは、関数内のロジックが変更されたかどうかを示すためです。まだ最適ではありません。あなたが必要としないテストを実行する外部モックに依存しているからです。なぜあなたはあなたのユニットをテストするために外部の嘲笑されたデータに頼りたいのですか？あなたはここであなただけplusOne()内部のロジックをテストし、あなたのサービスのための独立したテストを実装することができ、その後

describe('test',() => { 
    let instance: ClassToTest; 
    const mockedValue = 1; 
    beforeEach(() => { 
     instance = new ClassToTest(mockedValue); 
    }) 
    it('plusOne() should return the property "value" plus one',() => { 
     expect(instance.plusOne()).toBe(mockedValue + 1); 
    }) 
}); 

：

ここにあなたのユニットのロジックをテストするための最良の方法は、このような何かを行うことです。