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.
