On Wed, 4 Mar 2020 at 23:32, Warren Stephens <wsteph...@prognoshealth.com> wrote:
> Folks, > > First off thanks for the feedback! -- positive and negative. > > Second, hopefully people can trust that I fully understand the standard > approach to code refactoring and writing tests. I have done a bunch of it, > and am sure will continue to do a bunch of it. I understand the merits of > it. It is a valuable thing to do for the long run. No pejorative is > intended here. > > That said, I am trying to reset here with another example about a possible > new way to have good tests AND have code for which it is easy to quickly > understand the relationships between all sub-tasks of the code -- it is > modified code from *The Go Programming Language* book. Note: There is a > bunch of "goto nonsense" added to get the Go compiler to accept the 4 > labels for compiling. > > The attributes that I would like to highlight are: > > 1. a *single* function which accomplishes a complete task > 2. which is composed of *ordered* steps > 3. where some steps may have *sub-steps*, and perhaps sub-sub-steps > > I find your code to be a somewhat odd example to illustrate your point. - It's structured as a set of goroutines communicating over channels, but you've arranged things so that there is no concurrency - each goroutine runs from start to finish before the next one is started, so the goroutines and channels are entirely redundant. You might as well have used slices instead of channels. - The behaviour that you're wanting to test isn't easily available for testing, even if something like your proposal was accepted, because the only observable effects of the program involves printing to the standard output. - If the program was changed to be concurrent in the way that its structure suggests, then it no longer has the attributes that you're highlighting - it would no longer be composed of ordered steps, but of concurrent operations instead. - Programs composed of goroutines communicating over a channel are perfect for testing as independent functions, and arguably your program is easier to understand if it is broken up as such <https://play.golang.org/p/q0DNKwrp8sb>. - The entire example would actually be easy to test from the top level without testing the individual parts if the use of stdout was changed. - If you did test each sub-step, then the bug in step 2A would never be found, because it's only a bug when the code is used in context. Only then does it become clear that the assignment to v does nothing because that local variable is immediately thrown away afterwards. Having said all that, I believe there is a valid point to be made with regard to testing concurrent Go programs that have long-lived behaviour over time. It can be hard to test such programs, and I've not yet seen an approach that doesn't feel clunky and/or somewhat error-prone. However, as far as I can see, your proposal wouldn't help in that respect. -- 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/CAJhgacgDO0RpA9q2WjoGVWBqFY2r-0sGqL4Z2ukFQ9-ANH2i_w%40mail.gmail.com.
