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

Reply via email to