Bah, ignore the message below. The issue isn’t that EUnit has a problem with
nested directories, it’s that it expects each test module to have a `_tests`
suffix, not a `_test` one. We’re inconsistent about adhering to that rule in
our codebase I’ll submit a PR to fix the module names so no one else bumps into
that issue.
Adam
> On Nov 23, 2021, at 3:48 PM, Adam Kocoloski <kocol...@apache.org> wrote:
>
> Hi,
>
> TL;DR - I think it would be a good idea to move EUnit tests back into `test`
> instead of `test/eunit`.
>
> Recently I’ve been spending some time porting specific libraries to use
> rebar3 and I thought it might be a nice project to hack on supporting rebar3
> in CouchDB proper during the holiday weekend. I noticed a few small issues,
> but one in particular is that it was difficult to get rebar3 to pick up unit
> tests that were in subdirectories of `test`.
>
> Eventually I figured out that you could tell the compiler to do recursive
> compilation on these test directories and that worked for running the
> end-to-end test suite, but then I found that rebar3’s `—app` flag was still
> broken, e.g. if I ran `rebar3 eunit —app couch_log` it would only find tests
> in the actual source modules but not any of the modules in the test/eunit
> directory. I thought this might be an inconsistency bug in rebar3, but I
> realized that when you invoked rebar3 this way it was really just calling
> `eunit:test({application, couch_log})`, and EUnit doesn’t allow any
> configurability of its search path when invoked this way.
>
> Bottom line, it feels like we’re going against the grain of eunit itself when
> we try to move the eunit tests to anywhere else other than `test`. Currently
> we have a small handful of apps following this pattern:
>
> chttpd
> couch
> couch_epi
> couch_log
> couch_prometheus
> couch_replicator
>
> Of those, only the first two have any ExUnit unit tests that (I think)
> motivated the creation of separate eunit and exunit tests in the first place.
> Would it be OK if we moved those test modules back into `test` so we can stay
> on the “paved path” for EUnit usage going forward?
>
> Cheers, Adam
