Hi everyone!

I would like to a bit change our tests layout. Currently, we have
roughly the following picture:
- couchdb: javascript-based integration tests
- couchdb-couch: eunit both functional and integration tests
- couchdb-couch-replicator: eunit both functional and integration tests
- couchdb-mrview: eunit functional tests
- ... well, everything else is mostly third-party projects clones or
trivial cases that just works

The problem is that we keep test suites that starts full featured
server with all the components from subproject. To be clear about what
I'm talking take a look on any couchdb_* test suite for couchdb-couch
project:
https://github.com/apache/couchdb-couch/tree/master/test

I specially named them in this way to denote that they runs full
CouchDB server for own needs. While this "just works", it makes
impossible to test each component standalone, without dealing with the
deps.

So I propose to:
- Each subproject should have only test suite that his own
functionality. If it accidentally triggers some external dependency,
use meck and mock it.
- In top level, couchdb, repository, keep the tests which needs to
start whole CouchDB server instance with all the apps to run specific
tests.

That will gives us:
- Each subproject to be test-able standalone;
- All integration tests will be in one single place. This is important
since now we have 2 different httpd services which almost shares
testing methods: CORS is need to be tested against both chttpd and
httpd, vhosts is too, same is about proxying etc;
- Test helpers will be clearly decoupled: we wouldn't have to keep the
same helpers in each subproject to operate with server instance and we
avoid heavy coupling subprojects by test suites.

Count this as a little, but step forward to reusable subprojects. I
think we should have to provide couchdb-couch in this way to let
people use CouchDB core as embed database in their Erlang apps (hi,
cowdb! we're coming!).

Does everyone ok with such idea?

--
,,,^..^,,,

Reply via email to