Re: [go-nuts] Proposal: test in one package can import functions from another package's test
On Mon, Apr 08, 2019 at 08:33:44PM -0700, nanmu42 wrote:
> I don't know you, but to me, writing Golang test is a little dreary.
>
> As a discussion, I think this proposal could bring some improvement.
>
> How do you like it?
>
> https://github.com/golang/go/issues/31135
In your (admittedly contrived) example, I think a better solution would be to
provide your farm package with a mock result from the weather API call. For
example:
// farm/farm.go
package farm
// WaterVolume calculates the amount of water in liters to be applied when
// the temperature is t degrees celsius
func WaterVolume(t int) int {
return t * 5 // whatever
}
You could even do something like
// weather/weather.go
package weather
struct Weather {
Temperature int
}
// farm/farm.go
package farm
struct Farm {
wx *weather.Weather
}
func NewFarm(wx *weather.Weather) *Farm {
return {wx}
}
func (f *Farm) WaterVolume() int {
return f.wx.Temperature * 5
}
The added benefit of doing something like this is that you can cleanly separate
out what you're testing: do you really WANT to be testing your weather API calls
in the farm package?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Proposal: test in one package can import functions from another package's test
No, you are right, I really don't.
Thanks for your idea. I should consider decoupling those parts, in a
somehow nice way.
Ben Burwell 於 2019年4月9日 週二 下午8:10 寫道：
> On Mon, Apr 08, 2019 at 08:33:44PM -0700, nanmu42 wrote:
> > I don't know you, but to me, writing Golang test is a little dreary.
> >
> > As a discussion, I think this proposal could bring some improvement.
> >
> > How do you like it?
> >
> > https://github.com/golang/go/issues/31135
>
> In your (admittedly contrived) example, I think a better solution would be
> to
> provide your farm package with a mock result from the weather API call. For
> example:
>
> // farm/farm.go
> package farm
>
> // WaterVolume calculates the amount of water in liters to be applied
> when
> // the temperature is t degrees celsius
> func WaterVolume(t int) int {
> return t * 5 // whatever
> }
>
> You could even do something like
>
> // weather/weather.go
> package weather
>
> struct Weather {
> Temperature int
> }
>
> // farm/farm.go
> package farm
>
> struct Farm {
> wx *weather.Weather
> }
>
> func NewFarm(wx *weather.Weather) *Farm {
> return {wx}
> }
>
> func (f *Farm) WaterVolume() int {
> return f.wx.Temperature * 5
> }
>
> The added benefit of doing something like this is that you can cleanly
> separate
> out what you're testing: do you really WANT to be testing your weather API
> calls
> in the farm package?
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] Proposal: test in one package can import functions from another package's test
I don't know you, but to me, writing Golang test is a little dreary. As a discussion, I think this proposal could bring some improvement. How do you like it? https://github.com/golang/go/issues/31135 -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
