官網(wǎng)

• 所有代碼都必須被單元測試覆蓋。
• 每次測試測試一件事（在一個 it 里實現(xiàn)）。
• 單元測試將被測試的代碼與其依賴項隔離：模擬所有的依賴項。
• 單元測試需要相互獨立：我們應(yīng)該能夠以任何順序從文件運行測試，并且不會改變結(jié)果。
• 在適用時涵蓋快樂路徑、錯誤、邊緣情況和 UI。

UI Components

Mock Everything

與任何其他代碼段一樣，我們希望單獨測試 UI 組件。 我們不希望測試結(jié)果受到我們正在測試的類之外的代碼的影響。

雖然模擬服務(wù)之類的依賴關(guān)系更為明顯，但很容易忘記模擬從測試組件的模板中調(diào)用的子組件。

要模擬子組件，您可以在規(guī)范文件中創(chuàng)建它的假副本。 偽造組件必須與您要偽造的子組件具有相同的選擇器：

例子：

@Component({template: '',selector: 'cx-some-component' }) class MockSomeComponent {@Input() someparam; }

Then, you declare it in the TestBed:

TestBed.configureTestingModule({imports: [...],declarations: [MockSomeComponent],providers: [...], }).compileComponents();

NGRX and Tests That Use the Store

事實證明，模擬 NGRX 商店是一項相當大的挑戰(zhàn)。 NGRX 存儲是我們單元測試中模擬依賴項規(guī)則的例外。

要對從 store 讀取的一段代碼執(zhí)行單元測試，請通過使用數(shù)據(jù)顯式調(diào)用相關(guān)成功操作來填充 store 以設(shè)置測試。

這是我們調(diào)度 LoadUserAddressesSuccess 來設(shè)置測試數(shù)據(jù)的示例：

it('should be able to get user addresses', () => {const mockUserAddresses: Address[] = [{ id: 'address1' }, { id: 'address2' }];store.dispatch(new UserActions.LoadUserAddressesSuccess(mockUserAddresses));let addresses: Address[];service.getAddresses().subscribe(data => {addresses = data;}).unsubscribe();expect(addresses).toEqual([{ id: 'address1' }, { id: 'address2' }]); });

Avoiding Silently Failing Tests

最好的做法是刪除訂閱之外的斷言。 這樣，我們確保在測試完成之前執(zhí)行斷言。 為了斷言 observable 的結(jié)果，我們在訂閱中分配結(jié)果，但斷言是在訂閱之外用值完成的。

下列做法不推薦：

service.getAddresses().subscribe(addresses => {expect(addresses).toEqual([{ id: 'address1' }, { id: 'address2' }]);}).unsubscribe();});

下列才是推薦的做法：

let addresses: Address[];service.getAddresses().subscribe(data => {addresses = data;}).unsubscribe();expect(addresses).toEqual([{ id: 'address1' }, { id: 'address2' }]);});

總結(jié)

以上是生活随笔為你收集整理的SAP Spartacus 单元测试开发规范的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。