[almighty] White/Blackbox tests

[Andrew Lee Rubinger]

On Tue, Sep 27, 2016 at 12:03 PM, Thomas Mäder <tmader at redhat.com> wrote:

> Hi folks,
>
> https://github.com/almighty/almighty-core/pull/249 proposes separating
> whitebox (use whatever code you want) and blackbox (use public API only)
> tests into separate files as a general guideline.
>
> I feel separating the two tests does not add any value, it just makes
> adding tests more complicated. I'm not saying that we can't break up huge
> tests into multiple files, just that whitebox vs. blackbox is not a useful
> criterion to do so. And even if that separation might make sense, I feel it
> only does so in a limited number of cases and should not be a mandated or
> recommended practice.
>

I am not taking a position, but would like to point out that blackbox tests
calling upon a public API have the benefit of fewer dependencies.  If you
break them into a module that does not know about internal dependencies,
you can have high assurance that you are properly acting as a user of the
software and not accidentally depending upon internals.

This is the technique I've employed with some success over the years, and
I've separated things out for the reason mentioned above.  Black-box
testing is about playing the role of client without any other advantages.

S,
ALR


>
> Also, the proposed naming policy leads to_very_long_file_names.go which
> for me makes it harder to find the files I am looking for.
>
> Also, most packages I've seen don't seem to do it (argument by authority
> ;-))
>
> As an example, I don't think the tests in the models package have gained
> in clarity for being separated into whitebox and blackbox tests. If can
> make testing the API much simpler by calling an internal function, do I
> have to refrain from doing so?
>
> What's you're opinion?
>
> /Thomas
>
> _______________________________________________
> almighty-public mailing list
> almighty-public at redhat.com
> https://www.redhat.com/mailman/listinfo/almighty-public
>



-- 
Red Hat Developer Programs Architecture
@ALRubinger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20160927/d299d675/attachment.htm>