Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

[Bakul Shah]

On Mar 5, 2020, at 12:05 AM, roger peppe  wrote:
> 
> 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.

Dijkstra wrote "Testing reveals the presence, not the absence of bugs".
This is particularly true of concurrent programs! How do you ensure there
are no deadlocks? There may be too many states to test. And debugging is
even harder. How do recreate conditions for a deadlock when you don't
really know what may be the cause?

In contrast formal specification languages/tools such as TLA+/Coq/SPIN
seem to have made better headway. It would be good if specification
support can be integrated into Go. Or may be, have a separate language
analogous to the Bluespec language that can be compiled to Verilog.



-- 
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/58D60EAB-E90C-4F53-90D0-07751A232923%40bitblocks.com.

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

[David Riley]

On Mar 2, 2020, at 1:54 PM, Warren Stephens  wrote:
> 
> I have never experienced that writing tests at the beginning saves time.  I 
> find it is always faster to not write them in the beginning.  Functionality 
> typically changes 3 or 4 times before it "settles down" enough that writing 
> tests makes sense to me.

I'm not a TDD stan in the least, but I have to argue here that if this is the 
case, you're not spending enough time on requirements and use cases up front.  
You should be able to write a specification that can be tested against; if that 
changes in huge, significant ways such that you have to rewrite all your tests, 
you don't have a spec, you have a draft.  I'm aware that that is the reality 
for a lot of engineers, having worked under both kinds of domains, but that 
doesn't make it right.

Similarly, if your problem with writing tests for your own code refactored by 
someone else is that you can't understand the dataflow anymore, then the 
problem is that someone somewhere along the line has not sufficiently 
documented the code.  The solution is not to enable the retroactive insertion 
of crutches into the internals of a function, especially since tests should be 
verifying that the external interfaces of the unit under test conform to the 
specification. Internals should not even be visible to tests, which is why they 
usually aren't.

IMHO we should not be modifying Go to enable poor engineering methodologies, 
and reactive design is absolutely one of those.


- Dave

-- 
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/90C6F1DB-92E3-4161-86D4-3D79836A1F4D%40gmail.com.

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

[Tristan Colgate]

It is not possible to infer the intent of a chunk of code purely from
the expressions. You can see what it does, not what it meant to do.
One way of labeling the intent is to put that code in a function. A
well chosen name can let someone determine what the function was
intended to do, and fix it if it is doing something else. You can also
test that intention holds for some reasonable set of values, and
people can expand that set of values if they find ones for which that
function seems to do something else.

So, if the choice you propose is between an function with a series of
steps, all in line, vs a function with a series of named steps that
are elsewhere, then yes, I'll go with you're option one because I'd
rather read.

  func (a *thing) processThing() error{
a.tidyTheThing()
a.mungeTheThing()
a.augmentTheThing()
  }

Than a function of potentially unbounded length which is just a frenzy
of activity on that thing.

The problem is that you are advocating for what most people would
consider to be the day 1 programming experience, where experience and
industry best practice has show us that it is better to structure
things more clearly. You are the first person I've seen actually
advocate for this approach, where my own experience, and the
experience of every text I've read, advocates for the opposite.

On Tue, 3 Mar 2020 at 22:38, Warren Stephens
 wrote:
>
> rog,
>
> Very well said -- but everyone keeps talking about improving the 
> maintainability without talking about the "comprehensiblity".
>
> Look at the 2 things below.  Which is more quickly comprehensible?  We cannot 
> conceive of a way to have the upper one and still test each piece???
>
> Warren
>
> AAA
> BBB
>www
> CCC
>xxx
>   yyy
> DDD
>zzz
>
> ===
>
> AAA
> BBB
> www
> CCC
> xxx
> yyy
> DDD
> zzz
>
>
>
> --
> 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/be59057f-bd56-4b57-9e23-3c59b1153a47%40googlegroups.com.



-- 
Tristan Colgate-McFarlane

  "You can get all your daily vitamins from 52 pints of guiness, and a
glass of milk"

-- 
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/CAPGZSG%2B6KbYTOxeThC6PcxskGSXckebPb%2BUmJ6acp_e%3DRFO%3DRg%40mail.gmail.com.

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

[roger peppe]

On Tue, 3 Mar 2020 at 22:37, Warren Stephens 
wrote:

> rog,
>
> Very well said -- but everyone keeps talking about improving the
> maintainability without talking about the "comprehensiblity".
>
> Look at the 2 things below.  Which is more quickly comprehensible?  We
> cannot conceive of a way to have the upper one and still test each piece???
>

I'm interested to try to understand why you feel you can't write tests for
the former code by calling the top level entry point
(presumably AAA in your example). I feel that so many testing decisions are
only properly made in the context of the code itself. It's hard to talk
usefully about such things without any actual examples.  Perhaps you could
provide some Go code that you'd feel that you'd be forced to split up in
order to test (perhaps reduced in size or anonymized), so that we have
something concrete to talk about?

  cheers,
rog.


> Warren
>
> AAA
> BBB
>www
> CCC
>xxx
>   yyy
> DDD
>zzz
>
> ===
>
> AAA
> BBB
> www
> CCC
> xxx
> yyy
> DDD
> zzz
>
>
>
> --
> 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/be59057f-bd56-4b57-9e23-3c59b1153a47%40googlegroups.com
> 
> .
>

-- 
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/CAJhgacg_eTLDcO4%3DJ2PNAJTecreCVuRD2LwPSCa%2BOj8%3D273p%2BA%40mail.gmail.com.

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

['Axel Wagner' via golang-nuts]

On Tue, Mar 3, 2020 at 11:38 PM Warren Stephens 
wrote:

> Look at the 2 things below.  Which is more quickly comprehensible?  We
> cannot conceive of a way to have the upper one and still test each piece???
>

I don't really understand the point you are trying to make here. To me, the
upper one seems more comprehensible and represents what has been suggested
in this thread many times: To factor out the individual, separable pieces
of code into their own functions with their own contracts and test those.
As opposed to have one long run of statements.

Maybe that's an artifact of imprecise representation and abstraction - i.e.
maybe I don't understand correctly what you are trying to show with what
you draw out. But maybe, it's also an artifact of ideas like
"comprehensibility" (just like "readability") being overwhelmingly
subjective. Sure, there is a long tail of clearly bad code where enough
people can agree that it's incomprehensible, that we can talk about it
being "objectively" bad. But for the overwhelming majority of realistic
code where these questions come up, in my experience, reasonable people can
agree that either version would work fine and that it mostly comes down to
personal preference.

Personally, my working memory is severely limited. So, having separate
functions, allows me to treat them as individual units of comprehension,
that I can then compose into larger blocks, a few at a time.

(also, I want to once again point out that talking about "the real world"
and your "decades of experience" comes of as condescension, even if it
isn't intended as such. I don't think that serves your intention to
convince people of your view point)


> Warren
>
> AAA
> BBB
>www
> CCC
>xxx
>   yyy
> DDD
>zzz
>
> ===
>
> AAA
> BBB
> www
> CCC
> xxx
> yyy
> DDD
> zzz
>
>
>
> --
> 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/be59057f-bd56-4b57-9e23-3c59b1153a47%40googlegroups.com
> 
> .
>

-- 
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/CAEkBMfEHzbXZ_%2Bt9oSqyNFn9sPpr%2BL5vBZdCg82yQT7g9bbQrQ%40mail.gmail.com.

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

[Dan Kortschak]

The answer to that question is entirely dependent on context, which is
stripped by using anonymous labels as you have. For linear things, the
second one is clearer, for hierarchical things the first is.

It is entirely possible to test each piece of an hierarchical
structure; this is the basis for unit testing. If you take a look at
how Go authors conventionally write helpers (you'll see this throughout
the stdlib and in the golang.org/x packages) the naming conventions
foster an intelligibility, while factoring out code and so 1. making it
testable, and 2. preventing the details getting in the way of the
bigger picture (at each hierarchical level).

To be perfectly frank, providing a mechanism that allowed people to put
more code into functions, as the with system you're proposing appears
to, would IMO harm intelligibility and I'd reject code that used it in
PRs.

Dan

On Tue, 2020-03-03 at 14:37 -0800, Warren Stephens wrote:
> rog,
> 
> Very well said -- but everyone keeps talking about improving the
> maintainability without talking about the "comprehensiblity".
> 
> Look at the 2 things below.  Which is more quickly comprehensible? 
> We cannot conceive of a way to have the upper one and still test each
> piece???
> 
> Warren
> 
> AAA
> BBB
>www
> CCC
>xxx
>   yyy
> DDD
>zzz
> 
> ===
> 
> AAA
> BBB
> www
> CCC
> xxx
> yyy
> DDD
> zzz
> 
> 
> 
> -- 
> 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/be59057f-bd56-4b57-9e23-3c59b1153a47%40googlegroups.com
> .


-- 
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/4dd2dc98749307286eb346cc2c21b156ac70cf89.camel%40kortschak.io.

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

[Jason E. Aten]

Gentle suggestion: put each step you want to be testable into its own 
function.

AAA
BBB
   www()
CCC
   if xxx() {
  yyy()
   }
DDD
   zzz()

-- 
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/1666164a-1e66-4f30-893a-2af118280616%40googlegroups.com.

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

[Warren Stephens]

rog,

Very well said -- but everyone keeps talking about improving the 
maintainability without talking about the "comprehensiblity".

Look at the 2 things below.  Which is more quickly comprehensible?  We 
cannot conceive of a way to have the upper one and still test each piece???

Warren

AAA
BBB
   www
CCC
   xxx
  yyy
DDD
   zzz

===

AAA
BBB
www
CCC
xxx
yyy
DDD
zzz



-- 
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/be59057f-bd56-4b57-9e23-3c59b1153a47%40googlegroups.com.

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

[roger peppe]

> In my current project [...], I have not found a single problem using
programmed tests.

Automated tests play more roles than just finding initial problems.
Arguably more important is to guard against errors introduced when
maintaining and updating the code over time (regression). Tests are also a
liability as well as an asset. Sometimes updating tests when behaviour
changes can be very costly.

For the above reasons, I consider that when possible, it's much better to
write tests in terms of behaviour that really matters (using the public
API, as Robert Engels suggests) rather than using details of the internal
implementation.

If I wrote a bunch of tests using this "with" statement, then refactored
the code, how useful would those tests be? Would they guard against
behaviour regression? Would they really be more of an asset than a
liability over time?

Of course, it's not *always* possible to test using the external API, but
at least if you're testing a function, there's an obvious entry point and
implied contract that can be documented and maintained. That's not the case
if your tests are poking directly into local variables within the code.

In other words, I see this aspect of Go as appropriate design pressure
towards making more maintainable software, not a restriction that needs to
be worked around.

  cheers,
rog.

On Tue, 3 Mar 2020 at 12:15, Warren Stephens 
wrote:

> I really am not trying to be a pain about this "real world" thing -- think
> about trauma nurses and MASH surgeons.  I have 2 friends that are trauma
> nurses who fly on rescue helicopters to car and motorcycle crashes (or
> occasionally a military location).  They do not do things the same was as
> regular hospital nurses, and never will.  That is not a people management
> problem.  One of them is literally a "seasoned vet" of the National Guard.
>
> In my current project (which runs 24x7, like most things in my
> multi-decade experience, and for which I am "on call"), I have not found a
> single problem using programmed tests.  Sure I need to add some, but all of
> the real problems have been found by running "battlefield stress" tests --
> launching it 10,000 times rapidly to find, for instance, that the cloud
> vendor will sometimes unceremoniously kill the process at a random point in
> the program and restart it.
>
> The Agile Manifesto is all about cycling on working code.  My belief is
> that every cycle does not need test processes.  Add them over time, when
> the dust occasionally settles.
>
> --
> 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/859b245a-22c0-4c9f-a152-c63283ea5825%40googlegroups.com
> 
> .
>

-- 
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/CAJhgaci2vqUTuhx8056TNXZ7AiunZcH6wmMkWOYBHj__UrDO0g%40mail.gmail.com.

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

[Warren Stephens]

I really am not trying to be a pain about this "real world" thing -- think 
about trauma nurses and MASH surgeons.  I have 2 friends that are trauma 
nurses who fly on rescue helicopters to car and motorcycle crashes (or 
occasionally a military location).  They do not do things the same was as 
regular hospital nurses, and never will.  That is not a people management 
problem.  One of them is literally a "seasoned vet" of the National Guard.

In my current project (which runs 24x7, like most things in my multi-decade 
experience, and for which I am "on call"), I have not found a single 
problem using programmed tests.  Sure I need to add some, but all of the 
real problems have been found by running "battlefield stress" tests -- 
launching it 10,000 times rapidly to find, for instance, that the cloud 
vendor will sometimes unceremoniously kill the process at a random point in 
the program and restart it.

The Agile Manifesto is all about cycling on working code.  My belief is 
that every cycle does not need test processes.  Add them over time, when 
the dust occasionally settles. 

-- 
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/859b245a-22c0-4c9f-a152-c63283ea5825%40googlegroups.com.

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

[Bakul Shah]

On Mar 1, 2020, at 12:43 PM, Ian Lance Taylor  wrote:
> 
> On Sun, Mar 1, 2020 at 8:21 AM Warren Stephens
>  wrote:
>> 
>> // I don't want to get into the specific syntax of the test code directly,
>> // but a test would start execution here, supplying "lines" and "thing2"
>> //
>>mystep2 with: lines, thing2  // <-- hide all local variables from 
>> above except for lines and thing2
>> 
>>mymap := make(map[string]int)
>>   for _, line := range lines {
>>   if strings.Contains(line, thing2) {
>>   count := strings.Count(line, thing2)
>>   mymap[line] = count
>>}
>>   }
>> 
>> // and the test would end here -- because the next line is another "with" 
>> (or return) statement
>> // it would be able to do Asserts and such on the variables within the scope 
>> of this code segment
>> 
>> Ian,
>> 
>> An alternative approach would be to have:
>> 
>>   mystep2 with: lines, thing2 => mymap
>> 
>> to specify all of the intermediate variables of interest for the test.
>> 
>> These testable code chunks, delimited by with statements, act like hidden 
>> funcs.  The actual call could be something like test_doSomeStuff@mystep2
> 
> To me this all seems very unlike anything else in the Go language.
> There is nothing syntactically similar to this anywhere else.  I think
> it is extremely unlikely that Go would adopt this idea.

What Warren wants seems something like "Hoare Logic", where you have a
notation such as

P{C}R

where P & R are assertions and C is a block of code. If precondition P
is satisfied, after executing C the postcondition Q will be satisfied.
This can be used to build up in a stepwise manner the correctness "proof"
of a function.

See C.A.R.Hoare's 1969 paper, "An Axiomatic Basis for Computer Programming"
http://extras.springer.com/2002/978-3-642-63970-8/DVD3/rom/pdf/Hoare_hist.pdf

You can already do the equivalent of this in Go today if you want. IMHO any
additional syntax doesn't seem to buy anything. If my guess is wrong,
perhaps Warren can try to clearly describe the exact *semantics* he wants?
[Always a good idea!]

-- 
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/AF8FBEDE-9F72-4278-9172-5AD693D07DDB%40bitblocks.com.

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

[peterGo]

Fixed test.

Warren,

"The over-arching goal is for me to write tests more easily.  Not avoid 
writing tests.  I am not arguing against tests."

Here is a quick fix of your code;

ws.go: https://play.golang.org/p/KgQ0esiY0Xt

Now, use rdr to quickly test countSomeStuff:

ws_test.go: https://play.golang.org/p/K262-OIYa7e

ws
├── ws.go
└── ws_test.go

ws$ go test
PASS
ws$

Peter

On Monday, March 2, 2020 at 7:54:12 PM UTC-5, peterGo wrote:
>
> Warren,
>
> "The over-arching goal is for me to write tests more easily.  Not avoid 
> writing tests.  I am not arguing against tests."
>
> Here is a quick fix of your code;
>
> ws.go: https://play.golang.org/p/KgQ0esiY0Xt
>
> Now, use rdr to quickly test countSomeStuff:
>
> ws_test.go: https://play.golang.org/p/10mk88Preot
>
> ws
> ├── ws.go
> └── ws_test.go
>
> ws$ go test
> PASS
> ws$ 
>
> Peter
>
> On Monday, March 2, 2020 at 1:54:04 PM UTC-5, Warren Stephens wrote:
>>
>> The over-arching goal is for me to write tests more easily.  Not avoid 
>> writing tests.  I am not arguing against tests.
>>
>> Though I am being a bit snarky when I see responses that seem merely to 
>> say "Use TTD or something similar and it will solve all your problems!" 
>>
>> I have never experienced that writing tests at the beginning saves time.  
>> I find it is always faster to not write them in the beginning.  
>> Functionality typically changes 3 or 4 times before it "settles down" 
>> enough that writing tests makes sense to me.
>>
>> Warren
>>
>>

-- 
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/f25bcec3-6b8a-4236-8d2e-c6dc376de320%40googlegroups.com.

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

[peterGo]

Warren,

"The over-arching goal is for me to write tests more easily.  Not avoid 
writing tests.  I am not arguing against tests."

Here is a quick fix of your code;

ws.go: https://play.golang.org/p/KgQ0esiY0Xt

Now, use rdr to quickly test countSomeStuff:

ws_test.go: https://play.golang.org/p/10mk88Preot

ws
├── ws.go
└── ws_test.go

ws$ go test
PASS
ws$ 

Peter

On Monday, March 2, 2020 at 1:54:04 PM UTC-5, Warren Stephens wrote:
>
> The over-arching goal is for me to write tests more easily.  Not avoid 
> writing tests.  I am not arguing against tests.
>
> Though I am being a bit snarky when I see responses that seem merely to 
> say "Use TTD or something similar and it will solve all your problems!" 
>
> I have never experienced that writing tests at the beginning saves time.  
> I find it is always faster to not write them in the beginning.  
> Functionality typically changes 3 or 4 times before it "settles down" 
> enough that writing tests makes sense to me.
>
> Warren
>
>

-- 
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/7eb719bd-e5e5-4be4-b539-c1036814d7c8%40googlegroups.com.

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

[Robert Engels]

In the specific case you cite, it seems doubtful to me that you couldn’t 
properly test a 60 line method fully externally/black box

> On Mar 2, 2020, at 3:32 PM, Robert Engels  wrote:
> 
> 
> That’s where people management. Seasoned vets are better off devoting energy 
> to changing things than fighting fires - much better in the long run imo. 
> 
>>> On Mar 2, 2020, at 2:53 PM, Warren Stephens  
>>> wrote:
>>> 
>> 
>> Robert,
>> 
>> I just feel like (somehow invariably!) breaking 60 line methods into 3 
>> methods of 20 lines each is not the best ultimate solution.
>> 
>> As for the "real world" ...this is too funny.. I must live in a different 
>> one than most -- I have received 2 high-priority urgent requests since my 
>> previous post 1 hour ago!!!
>> 
>> The stuff I wrote even yesterday will have to wait.  Ha! ha!
>> 
>> Warren
>>  
>> -- 
>> 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/e8fbdb4e-1d02-42c5-9c1e-409a846caaa4%40googlegroups.com.

-- 
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/E0F666E8-1225-4655-BF6C-1C5F679899E0%40ix.netcom.com.

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

[Robert Engels]

That’s where people management. Seasoned vets are better off devoting energy to 
changing things than fighting fires - much better in the long run imo. 

> On Mar 2, 2020, at 2:53 PM, Warren Stephens  
> wrote:
> 
> 
> Robert,
> 
> I just feel like (somehow invariably!) breaking 60 line methods into 3 
> methods of 20 lines each is not the best ultimate solution.
> 
> As for the "real world" ...this is too funny.. I must live in a different one 
> than most -- I have received 2 high-priority urgent requests since my 
> previous post 1 hour ago!!!
> 
> The stuff I wrote even yesterday will have to wait.  Ha! ha!
> 
> Warren
>  
> -- 
> 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/e8fbdb4e-1d02-42c5-9c1e-409a846caaa4%40googlegroups.com.

-- 
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/B6F26A90-86DB-4B6C-9FFF-02DB331D5134%40ix.netcom.com.

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

[Warren Stephens]

Robert,

I just feel like (somehow invariably!) breaking 60 line methods into 3 
methods of 20 lines each is not the best ultimate solution.

As for the "real world" ...this is too funny.. I must live in a different 
one than most -- I have received 2 high-priority urgent requests since my 
previous post 1 hour ago!!!

The stuff I wrote even yesterday will have to wait.  Ha! ha!

Warren
 

-- 
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/e8fbdb4e-1d02-42c5-9c1e-409a846caaa4%40googlegroups.com.

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

[Robert Engels]

Then, as someone else pointed out, use black-box testing. Test only the public/external API. If your code is too complex to be tested this way, that's a sign of structure than needs to be refactored.I don't think "it's the real world" will get much traction here - people that maybe started their careers the way you describe, changed their tune or left the business.-Original Message-
From: Warren Stephens 
Sent: Mar 2, 2020 12:54 PM
To: golang-nuts 
Subject: Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

The over-arching goal is for me to write tests more easily.  Not avoid writing tests.  I am not arguing against tests.Though I am being a bit snarky when I see responses that seem merely to say "Use TTD or something similar and it will solve all your problems!" I have never experienced that writing tests at the beginning saves time.  I find it is always faster to not write them in the beginning.  Functionality typically changes 3 or 4 times before it "settles down" enough that writing tests makes sense to me.Warren



-- 
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/26bba248-8a7c-453b-83ee-ae4043c7b4c1%40googlegroups.com.




-- 
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/276419913.2168.1583175779379%40wamui-fuzz.atl.sa.earthlink.net.

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

[Warren Stephens]

The over-arching goal is for me to write tests more easily.  Not avoid 
writing tests.  I am not arguing against tests.

Though I am being a bit snarky when I see responses that seem merely to say 
"Use TTD or something similar and it will solve all your problems!" 

I have never experienced that writing tests at the beginning saves time.  I 
find it is always faster to not write them in the beginning.  Functionality 
typically changes 3 or 4 times before it "settles down" enough that writing 
tests makes sense to me.

Warren

-- 
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/26bba248-8a7c-453b-83ee-ae4043c7b4c1%40googlegroups.com.

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

[Tristan Colgate]

While pure TDD as defined by its canonical text can be frustrating and time
consuming, simply not writing tests is not really a defensible position,
and definitely not one that Go, or any other language, should attempt to
make easier.
  Writing testable code, and writing tests, does not have to mean TDD. In
my experience it always results in better code, and us tasty slower to
write because you spend less time in dead ends.
  I've done my share of time restricted, stream of consciousness
programming. The results are almost always unmaintainable.
  Saying you should write tests, and write code intending to be tested, is
the right kind of virtue signalling. Tests are one of the few things we
have that gives any meaning to words Software Engineer.


On Mon, 2 Mar 2020, 13:45 Warren Stephens, 
wrote:

> Misha,
>
> Wonderful!  This view is the furtherest away from mere TDD "virtue
> signaling"!
>
> Warren
>
> --
> 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/9e906437-f68f-4564-b7dc-1af31c4eb7cd%40googlegroups.com
> 
> .
>

-- 
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/CAPGZSGKY49u8Ju2NyR_tj0oWVjHTgsnR%3DnJLt_k5GknK%2Beuaew%40mail.gmail.com.

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

[Warren Stephens]

Misha,

Wonderful!  This view is the furtherest away from mere TDD "virtue 
signaling"!

Warren

-- 
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/9e906437-f68f-4564-b7dc-1af31c4eb7cd%40googlegroups.com.

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

[Mikhail Gusarov]

On 2 Mar 2020, at 13:54, Warren Stephens wrote:

Note to others: Software *Engineers* must operate with the 3-way 
tradeoff

in mind (pick 2 is the old joke):

   1. quality (good)
   2. time (fast)
   3. cost (cheap)


Well, if you are taking "engineering" out of sheaf, then the following 
essential

parts of any engineering project also deserve a mention:

4. lifecycle (varying)
5. stakeholder roles and their preferences

A. Throwaway write-once, execute-once code.

Stakeholder roles (often both roles are played by the same person) and 
their preferences:

- Developer. Write ASAP, debug ASAP
- Code user. Get the answer quickly and cheaply.

Does not need tests. `with` is irrelevant.

Z. Write once, maintain for 50 years code.

Stakeholder roles and their preferences (roughly):
- Original developer.
  Write ASAP, debug ASAP, not to be hassled by maintainer and users.

- Maintenance developer.
  Fix bugs, add features as expediently as possible. Not to break 
anything.


- Operating engineer.
  Make the code work reliably to not be woken up during outages.

- Technical writer.
  Provide documentation for maintenance developer, users, operator as 
fast as possible.


- Users.
  Get the benefit, have bugs and features implemented as fast as 
possible.


- Financier.
  Cost of development, operations and maintenance as low as possible.

- Project manager.
  Time to fix bugs and add features as low as possible.

- ... the list can go on and on

The price of writing the code for the first time and covering with tests 
if

it was written without tests in this case is irrelevant.

N. Code that was written once in a hurry, needs to be covered by tests, 
and does
not change often enough and radical enough to expose brittleness of the 
tests.


That's the sweet spot. Is there much code like this, and is this 
use-case

important enough?

--
Misha

--
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/2EA1CFFB-5675-4F6F-A6F5-F5FF9CCC0669%40ridge.co.

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

[Nigel Tao]

On Mon, Mar 2, 2020 at 8:06 AM Warren Stephens
 wrote:
> It could made to look more Go-like...
>
>internal mystep2(lines, thing2): (mymap, err)

Ian isn't talking about the particular syntax (e.g. punctuation or
keywords). He is talking about the semantics (statements that hide
scope, hidden funcs) being unlike anything else in Go.

Making a language change is a big deal, especially if there's plenty
of existing code out there that uses "with" as a variable name, and
the fact that not everyone upgrades to version N+1 at the same time.

But you don't need a language change (or to wait e.g. 6 months for the
toolchain release a new stable version). See
https://blog.golang.org/generate and
https://play.golang.org/p/vIXRLTnGlRf

-- 
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/CAOeFMNVsYaVUcyZyMVdAFshdOdWwueNsOU-1OQcar3tc4bnhrg%40mail.gmail.com.

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

[Warren Stephens]

Also note that these *internal* pieces of code would eliminate the 
inefficiency of calls -- which is non-trivial as I am sometimes dealing 
with big-data of billions of records of data.

-- 
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/052a96f5-1b9c-47b6-bd5d-009cbeda197e%40googlegroups.com.

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

[Warren Stephens]

No worries.  It could made to look more Go-like...

   internal mystep2(lines, thing2): (mymap, err)

or something like that.  Where "internal" is like "func".  The colon is 
already used for labels.  And the results are like the values supplied 
after a return. 

-- 
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/c929cab3-d0a9-4e90-a312-a07ca7f477e4%40googlegroups.com.

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

[Ian Lance Taylor]

On Sun, Mar 1, 2020 at 8:21 AM Warren Stephens
 wrote:
>
> // I don't want to get into the specific syntax of the test code directly,
> // but a test would start execution here, supplying "lines" and "thing2"
> //
> mystep2 with: lines, thing2  // <-- hide all local variables from 
> above except for lines and thing2
>
> mymap := make(map[string]int)
>for _, line := range lines {
>if strings.Contains(line, thing2) {
>count := strings.Count(line, thing2)
>mymap[line] = count
> }
>}
>
> // and the test would end here -- because the next line is another "with" (or 
> return) statement
> // it would be able to do Asserts and such on the variables within the scope 
> of this code segment
>
> Ian,
>
> An alternative approach would be to have:
>
>mystep2 with: lines, thing2 => mymap
>
> to specify all of the intermediate variables of interest for the test.
>
> These testable code chunks, delimited by with statements, act like hidden 
> funcs.  The actual call could be something like test_doSomeStuff@mystep2

To me this all seems very unlike anything else in the Go language.
There is nothing syntactically similar to this anywhere else.  I think
it is extremely unlikely that Go would adopt this idea.

Ian

-- 
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/CAOyqgcWqFF5tdwYCm5eRM7kXO6v9sD2ERaig2KGruasn0G-Y4Q%40mail.gmail.com.

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

[Warren Stephens]

Robert,

To me, code broken up into smaller pieces can “seem” more maintainable, but 
(actually more importantly to me) often is far less comprehensible.  And I 
must comprehend it in order to maintain it.

I recently returned to a piece of code that someone else had refactored in 
order to write tests.  I found that I no longer understood my own code.  
Where does the such-and-such get done now???  This calls that, and that 
calls that, and so forth.  Like a Russian Doll.  I could have used a 
diagram.  And any errors have to bubble up out of that stuff.  Thankfully 
better error wrapping has been added to Go.

I guess everyone doesn’t think the same way.  I am very top-down sequence 
oriented.  I don’t like to jump around in code in order to figure out what 
is going on.

Also, I believe that *with* statements could provide two additional 
benefits (in addition to making tests easier to write without refactoring):

1) Allow someone to read source code from top to bottom, paying most 
attention to the *with* statements, and come away with a quick 
understanding of the code.

2) Correct the problem that Go has with the common “err” variable.  Err 
could be redeclared in each section of *with* code — enforcing that each 
section is dealing with its own “err” values.  Err would not drop thru 
unless specifically listed.

Warren

-- 
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/9840e599-b001-4cfa-b6fd-35227b18b80d%40googlegroups.com.

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

[Robert Engels]

If you need to test your code that way it needs a better design. If the 
internal code within the function under test is trivial then testing purely the 
outer function will suffice. If the internal code is that complex it should be 
its own non-exported function that can be documented and tested in isolation. 
It will pay dividends to future maintainers. 

> On Mar 1, 2020, at 10:21 AM, Warren Stephens  
> wrote:
> 
> 
> // I don't want to get into the specific syntax of the test code directly,
> // but a test would start execution here, supplying "lines" and "thing2"
> //
> mystep2 with: lines, thing2  // <-- hide all local variables from 
> above except for lines and thing2
> 
> mymap := make(map[string]int)
> for _, line := range lines {
> if strings.Contains(line, thing2) {
> count := strings.Count(line, thing2)
> mymap[line] = count
>  }
> }
> 
> // and the test would end here -- because the next line is another "with" (or 
> return) statement
> // it would be able to do Asserts and such on the variables within the scope 
> of this code segment
> 
> Ian,
> 
> An alternative approach would be to have:
> 
>mystep2 with: lines, thing2 => mymap
> 
> to specify all of the intermediate variables of interest for the test.
> 
> These testable code chunks, delimited by with statements, act like hidden 
> funcs.  The actual call could be something like test_doSomeStuff@mystep2
> 
> Warren
> 
>> 
>> I feel like there is something missing here.  How do you write a test 
>> that uses a with statement? 
>> 
>> Ian 
> 
> -- 
> 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/f18a9af6-240b-4f3c-a011-6d68ed69784e%40googlegroups.com.

-- 
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/FF19D324-701B-4FD3-AE8F-884851E90F26%40ix.netcom.com.

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

[Warren Stephens]

// I don't want to get into the specific syntax of the test code directly, 
   
// but a test would start execution here, supplying "lines" and "thing2"
//
mystep2 with: lines, thing2  // <-- hide all local variables 
from above except for lines and thing2

mymap := make(map[string]int)
   for _, line := range lines {
   if strings.Contains(line, thing2) {
   count := strings.Count(line, thing2)
   mymap[line] = count
}
   }

// and the test would end here -- because the next line is another "with" 
(or return) statement
// it would be able to do Asserts and such on the variables within the 
scope of this code segment

Ian,

An alternative approach would be to have:

   mystep2 with: lines, thing2 => mymap

to specify all of the intermediate variables of interest for the test.

These testable code chunks, delimited by *with* statements, act like hidden 
*func*s.  The actual call could be something like *test_doSomeStuff@mystep2*

Warren


> I feel like there is something missing here.  How do you write a test 
> that uses a with statement? 
>
> Ian 
>

-- 
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/f18a9af6-240b-4f3c-a011-6d68ed69784e%40googlegroups.com.

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

[Ian Lance Taylor]

On Sat, Feb 29, 2020 at 10:11 AM Warren Stephens
 wrote:
>
> The labelled with statements would allow for a test to be written 
> specifically for each step of a function.
>
> Each test would begin at the with statement, providing the variables and 
> values required, and end at the next with statement or return statement.
>
> Each step of a function could be tested (or not) without having to refactor 
> the function into testable pieces
> which would lose the natural structure of the original code.

I feel like there is something missing here.  How do you write a test
that uses a with statement?

Ian

-- 
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/CAOyqgcW0ZSB8MxRa9pz-gGVcxg8HSP_AmyXx9djU-K65ir%3DDTg%40mail.gmail.com.

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

[Dan Kortschak]

Why can't you spell "with" as "func"?

On Sat, 2020-02-29 at 06:16 -0800, Warren Stephens wrote:
> I often write a function or module to handle some process that takes
> 3 or 4 steps to complete.
> 
> After I am happy with the code I then proceed to write tests for the
> code, 
> but find that I am compelled to chop the code into pieces in order to
> simplify the test code 
> -- thereby losing the nice top down readability with which I started.
> 
> The influence that test code has on the structure of the application
> code is highly undesirable.
> 
> Test code should not exert so much influence over how the primary
> code is written.
> 
> Here is a proposal that could eliminate this influence -- see
> explanation for with statements at the end.
> 
> 
> package main
> 
> import (
>   "bufio"
>   "fmt"
>   "os"
>   "strings"
> )
> 
> func main() {
> 
>   fmt.Printf("Hello folks!\n")
>   result, err := doSomeStuff("filename.txt", "find_these", 10)
>   if err != nil {
>   fmt.Printf("doThisStuff did not succeed! %v\n", err)
>   }
>   fmt.Printf("result length is: %v\n", len(result))
> }
> 
> func doSomeStuff(thing1 string, thing2 string, thing3 int)
> (map[string]int, error) {
> 
>   mystep1 with: thing1 // <-- hide all function
> parameters except for thing1
> 
>   file, err := os.Open(thing1)
>   if err != nil {
>   return nil, err
>   }
>   defer file.Close()
> 
>   var lines []string
>   scanner := bufio.NewScanner(file)
>   for scanner.Scan() {
>   lines = append(lines, scanner.Text())
>   }
>   err = scanner.Err()
>   if err != nil {
>   return nil, err
>   }
> 
>   mystep2 with: lines, thing2  // <-- hide all local
> variables from above except for lines and thing2
> 
>   mymap := make(map[string]int)
>   for _, line := range lines {
>   if strings.Contains(line, thing2) {
>   count := strings.Count(line, thing2)
>   mymap[line] = count
>   }
>   }
> 
>   mystep3 with: mymap, thing3 // <-- hide all local
> variables from above except for mymap and thing3
>   for k, v := range mymap {
>   if v > thing3 {
>   mymap[k] = 0
>   }
>   }
> 
>   return mymap, nil
> }
> 
> The labelled with statements would allow for a test to be written
> specifically for each step of a function.  
> 
> Each test would begin at the with statement, providing the variables
> and values required, and end at the next with statement or return
> statement.
> 
> Each step of a function could be tested (or not) without having to
> refactor the function into testable pieces
> which would lose the natural structure of the original code.
> 
> -- 
> 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/8eb18eb2-69e7-404a-86be-6c7893a9a7c1%40googlegroups.com
> .


-- 
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/110c02dbece55901d4c4d0f7a390655c8af5da21.camel%40kortschak.io.

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

[Mhd Shulhan]

Pada tanggal Min, 1 Mar 2020 01.11, Warren Stephens <
wsteph...@prognoshealth.com> menulis:

> I often write a function or module to handle some process that takes 3 or
> 4 steps to complete.
>
> After I am happy with the code I then proceed to write tests for the code,
> but find that I am compelled to chop the code into pieces in order to
> simplify the test code
> -- thereby losing the nice top down readability with which I started.
>
> The influence that test code has on the structure of the application code
> is highly undesirable.
>
> Test code should not exert so much influence over how the primary code is
> written.
>


In my experiences, it is a good things that the test code has influence to
the structure of application code, because if the code can not be easily
tested, there is something wrong with how I solve the problem, or maybe I
need to break it down into smaller unit and test only some parts of unit.


> The labelled *with* statements would allow for a test to be written
> specifically for each step of a function.
>
> Each test would begin at the *with* statement, providing the variables
> and values required, and end at the next *with* statement or return
> statement.
>

Now the application code are mixed with the test functionality. This is not
good design. Testing and application code are different domain, even if its
in the same repository.


> Each step of a function could be tested (or not) without having to
> refactor the function into testable pieces
> which would lose the natural structure of the original code.
>

-- 
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/CAMh9%2BYBgYzLW6p9bqk5gR--GjVdwviBUC7a%2BrKs-7srNfx5J9g%40mail.gmail.com.

[go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

[Warren Stephens]

I often write a function or module to handle some process that takes 3 or 4 
steps to complete.

After I am happy with the code I then proceed to write tests for the code, 
but find that I am compelled to chop the code into pieces in order to 
simplify the test code 
-- thereby losing the nice top down readability with which I started.

The influence that test code has on the structure of the application code 
is highly undesirable.

Test code should not exert so much influence over how the primary code is 
written.

Here is a proposal that could eliminate this influence -- see explanation 
for *with* statements at the end.


package main

import (
"bufio"
"fmt"
"os"
"strings"
)

func main() {

fmt.Printf("Hello folks!\n")
result, err := doSomeStuff("filename.txt", "find_these", 10)
if err != nil {
fmt.Printf("doThisStuff did not succeed! %v\n", err)
}
fmt.Printf("result length is: %v\n", len(result))
}

func doSomeStuff(thing1 string, thing2 string, thing3 int) (map[string]int, 
error) {

mystep1 with: thing1 // <-- hide all function parameters except for 
thing1

file, err := os.Open(thing1)
if err != nil {
return nil, err
}
defer file.Close()

var lines []string
scanner := bufio.NewScanner(file)
for scanner.Scan() {
lines = append(lines, scanner.Text())
}
err = scanner.Err()
if err != nil {
return nil, err
}

mystep2 with: lines, thing2  // <-- hide all local variables from 
above except for lines and thing2

mymap := make(map[string]int)
for _, line := range lines {
if strings.Contains(line, thing2) {
count := strings.Count(line, thing2)
mymap[line] = count
}
}

mystep3 with: mymap, thing3 // <-- hide all local variables from 
above except for mymap and thing3
for k, v := range mymap {
if v > thing3 {
mymap[k] = 0
}
}

return mymap, nil
}

The labelled *with* statements would allow for a test to be written 
specifically for each step of a function.  

Each test would begin at the *with* statement, providing the variables and 
values required, and end at the next *with* statement or return statement.

Each step of a function could be tested (or not) without having to refactor 
the function into testable pieces
which would lose the natural structure of the original code.

-- 
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/8eb18eb2-69e7-404a-86be-6c7893a9a7c1%40googlegroups.com.