3 回答

TA貢獻(xiàn)1824條經(jīng)驗(yàn) 獲得超6個(gè)贊
這不是直接支持的,即使有一個(gè)未解決的問題(stretchr/testify/issue 741 "assert mock calls in order")
更一般的問題684“斷言調(diào)用順序?” 包括反駁:
IMO 你應(yīng)該檢查函數(shù)的輸出,而不是它在內(nèi)部是如何工作的。它可能會(huì)導(dǎo)致很難維護(hù)的測試實(shí)現(xiàn)。
雖然,在同一個(gè)線程中:
IMO 有強(qiáng)制執(zhí)行命令的情況。即如果你模擬一個(gè)互斥鎖,你最好檢查在解鎖之前總是調(diào)用鎖。
我們可以有一個(gè)簡單的實(shí)現(xiàn),其中模擬有一個(gè)“assertExpectationsInOrder
”真/假標(biāo)志,可以在添加任何期望之前設(shè)置。
這可能會(huì)導(dǎo)致一些測試,例如cassandra-operator/cmd/operator/controller_test.go
哪些記錄事件來測試他們的訂單。

TA貢獻(xiàn)1801條經(jīng)驗(yàn) 獲得超8個(gè)贊
IMO 有強(qiáng)制執(zhí)行命令的情況。即如果你模擬一個(gè)互斥鎖,你最好檢查在解鎖之前總是調(diào)用鎖。
這是一個(gè)簡單的單線程實(shí)現(xiàn):
func TestOrderOfMocks(t *testing.T) {
order := 0
amock := new(AMock)
amock.On("Execute").Run(func(args mock.Arguments) {
if order++; order != 1 {
t.Fail()
}
})
bmock := new(BMock)
bmock.On("Execute").Run(func(args mock.Arguments) {
if order++; order != 2 {
t.Fail()
}
})
c := &Composition{amock, bmock}
err := c.Apply()
require.NoError(t, err)
}
PLAYGROUND
如果有原因,您可以使訂單檢查邏輯復(fù)雜化......

TA貢獻(xiàn)1856條經(jīng)驗(yàn) 獲得超11個(gè)贊
正如其他人所說,這是一個(gè)內(nèi)部細(xì)節(jié),并且確實(shí)將您的測試與實(shí)現(xiàn)糾纏在一起。如果您確定訂單很重要,這將毫無意義。在這里保持簡潔是另一種使用最低限度測試訂單的解決方案。
創(chuàng)建兩個(gè)實(shí)現(xiàn) InterfaceA 和 InterfaceB 的間諜。
type SpyA struct {
Calls *[]string
}
func (s *SpyA) Execute() {
*s.Calls = append(*s.Calls, "ExecuteA")
}
type SpyB struct {
Calls *[]string
}
func (s *SpyB) Execute() {
*s.Calls = append(*s.Calls, "ExecuteB")
}
然后像這樣使用它們。
func TestApply(t *testing.T) {
got := []string{}
c := &Composition{
a: &SpyA{&got},
b: &SpyB{&got},
}
c.Apply()
expected := []string{"ExecuteA", "ExecuteB"}
if len(got) != len(expected) {
t.Fail()
}
for i := range got {
if got[i] != expected[i] {
t.Fail()
}
}
}
- 3 回答
- 0 關(guān)注
- 174 瀏覽
添加回答
舉報(bào)