lundi 25 novembre 2019

Change real code behavior for test simplification - is it OK?

We have an object which using another object as an interface. While real usage (in production) this interface should not be nil, so we should be sure that we can call it otherwise we will get panic instead.

Is it appropriate to use it as nil instead and check if it is nill -> don't call it, log this while real usage. It was made for simpler object usage in tests.

IMO I think in this case we should use mock or stub in tests if we don't have scenarios for real usage when sub-object will intentionally be nil.

Very interesting to have some links to official recommendation documents for Golang or general development at least.

E.g.:


type Caller interface {
Call()
}

type ObjectA struct{
ObjectB Caller
}

func (o *ObjectA) SomeFunc() {
if o.ObjectB == nil {
log.Error("can't call ObjectB cause it is nil")
} else {
o.ObjectB.Call()
}
}

Aucun commentaire:

Enregistrer un commentaire