All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brad Bishop <bradleyb@fuzziesquirrel.com>
To: Andrew Jeffery <andrew@aj.id.au>
Cc: Patrick Venture <venture@google.com>,
	OpenBMC Maillist <openbmc@lists.ozlabs.org>,
	Emily Shaffer <emilyshaffer@google.com>
Subject: Re: YASL Request
Date: Fri, 13 Apr 2018 11:21:04 -0400	[thread overview]
Message-ID: <A920519B-A2F5-44BB-80D5-73EC81827448@fuzziesquirrel.com> (raw)
In-Reply-To: <1523591789.2710142.1336453024.5787B0DF@webmail.messagingengine.com>


> On Apr 12, 2018, at 11:56 PM, Andrew Jeffery <andrew@aj.id.au> wrote:
> 
> 
> Some advantages I've found to this technique are:
> 
> * There's no reduction of readability in the code

This.

> * You get test binaries that you can run independent of your test framework, as there isn't really a test framework, just autotools running your test binaries in parallel
> * By extension, if you need to debug a failing test case, you can gdb the test binary directly without needing to comprehend the side-effects of the test framework on your test binary

And this.  

Honestly these are my _real_ objections but I brought up runtime overhead because
that is not subjective.  I just don’t like how the direction we are headed
obfuscates things for developers that have a good understanding of standard libraries,
tools, and language features (libc, libstd++, STL, GDB, etc...) and don’t have an
understanding of the internals of GMock or the “techniques" its use drives into the
code.  I expect there to be way more of the former (those up to speed on the standard
libraries, tools, language features) than the latter (those comfortable working on
a GMock inspired codebase).

IMHO these concepts have a greater (positive) impact on the project overall than
super-easy-unit-test writing.  I’d guess I’m in the minority, but hey…I have to
speak my mind right?  I can certainly relate to the opposing viewpoint.

  reply	other threads:[~2018-04-13 15:21 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-09 22:27 YASL Request Patrick Venture
2018-04-10  2:45 ` Lei YU
2018-04-10  3:19   ` Patrick Venture
2018-04-10 17:59     ` Patrick Venture
2018-04-11  3:52   ` Brad Bishop
2018-04-11 15:59     ` Patrick Venture
2018-04-11  2:34 ` Brad Bishop
2018-04-11 15:56   ` Patrick Venture
2018-04-12 14:25   ` Alexander Amelkin
2018-04-12 15:20     ` Patrick Venture
2018-04-13 10:16       ` Alexander Amelkin
2018-04-13 15:42         ` Patrick Venture
2018-04-13  3:56 ` Andrew Jeffery
2018-04-13 15:21   ` Brad Bishop [this message]
2018-04-13 16:03     ` Patrick Venture
2018-04-14  0:14       ` Patrick Venture
2018-04-16  2:50     ` Lei YU
2018-04-16 19:10       ` Patrick Venture
2018-04-14  4:12   ` Patrick Venture

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=A920519B-A2F5-44BB-80D5-73EC81827448@fuzziesquirrel.com \
    --to=bradleyb@fuzziesquirrel.com \
    --cc=andrew@aj.id.au \
    --cc=emilyshaffer@google.com \
    --cc=openbmc@lists.ozlabs.org \
    --cc=venture@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.