Tests that depend on the internal implementation of a function are very brittle: any refactoring and they're likely to break, which defeats much of the benefit.
You can check that a function has the required visible behaviour without hooking directly into its internals, by comparing the state of the system before and after the function call. Or you can check for side effects as they happen by passing in mock objects - even then, too much of this can make tests brittle. Removing function calls in the name of efficiency is a case of premature optimisation. Unless you have profiling which shows that this code is on the hot path in your application, it won't make any difference. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/818b002c-a7ee-4f0a-86ef-7c9247999cc4%40googlegroups.com.
