> 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 <wsteph...@prognoshealth.com>
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
> <https://groups.google.com/d/msgid/golang-nuts/859b245a-22c0-4c9f-a152-c63283ea5825%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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.
