Great response. Thank you.

You've given me a lot to think about.

On Wednesday, 14 March 2018 01:38:53 UTC+10, matthe...@gmail.com wrote:
>
> I have less than ten years of experience doing this, but:
>
> The rule is that if you don’t verify it then it’s going to break in 
> deployment, 100% of the time.
>
> In my experience you can get away without testing small changes with 
> software if you’re very careful about verifying the change with manual 
> testing. For larger applications it’s also possible to get away with it, 
> but there will be all kinds of problems along the way.
>
> Tests can give a false sense of security; if there’s a large body of tests 
> for an application then passing them with a change can feel good enough, 
> but those tests only ever cover a subset of everything that can go wrong. 
> So you still have to do the manual verification. But the idea of automatic 
> tests as part of the build process is excellent because a lot of mistakes 
> can be caught that way.
>
> I’m not in the camp of 100% unit test coverage because then we’re backing 
> up against the “engineers working on the bike shed instead of the nuclear 
> reactor” problem, and test coverage can start looking like being paid by 
> lines of code written. What’s important is test methodology, which likely 
> includes unit tests, but should also include other forms of wider testing 
> (like just playing with the application, random clicking or inputs, 
> verifying output with a script).
>
> For my web application my favorite has been a load test script that acts 
> like many concurrent clients inputting valid and random inputs. This test 
> has found rare deadlocks, app logic problems, and other things that would 
> have only appeared with many users and would have been hard to reproduce.
>
> I've noticed the testing camp is split three ways: some people hate tests, 
>> some people don't get them or struggle with them, and some people love 
>> them. What are your thoughts? 
>
>
> People should learn to love software tests because it multiplies their 
> effectiveness as a software engineer.
>
> I think the idea of checking for impossible conditions in Go code is a 
> worthwhile effort too (via Steve Maguire's "Writing Solid Code"):
>
> const debug = false
> …
>     if debug {
>         if impossibleCondition {
>             panic(“impossible condition”)
>         }
>     }
>
> Matt
>
> On Tuesday, March 13, 2018 at 1:11:56 AM UTC-5, Mike Crilly wrote:
>>
>> I'm keen to understand if and how people are doing unit, module, and 
>> system tests for their Go applications. I've noticed the testing camp is 
>> split three ways: some people hate tests, some people don't get them or 
>> struggle with them, and some people love them. What are your thoughts? 
>>
>>
>> If you're somewhere in the middle, is it because you're unsure as to how 
>> to actually write the tests, what tools to use, how to make it easier, and 
>> so? What's stopping you from implementing them?
>>
>>
>> All thoughts welcome.
>>
>

-- 
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.

Reply via email to