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.
