couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <kxe...@gmail.com>
Subject Re: [PROPOSAL] CouchDB tests organization
Date Wed, 29 Apr 2015 15:07:30 GMT
Hi,

Seems nobody against that so I'm going to proceed on this.

Side question: I just recall that there was an idea to move javascript
test suite into own repository - Jan, is that yours? - in order to
make it reusable for PouchDB project and friends. I like this idea
even more, and following this schema it will make top level repo clean
from any code, while make tests as own subprojects which could be
easily changed / extended. What do you think?

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


On Mon, Jan 19, 2015 at 6:53 PM, Jan Lehnardt <jan@apache.org> wrote:
> Sounds sensible to me :)
>
> Good job there!
>
> Best
> Jan
> --
>
>> On 13 Jan 2015, at 19:24 , Alexander Shorin <kxepal@gmail.com> wrote:
>>
>> 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?
>>
>> --
>> ,,,^..^,,,
>

Mime
View raw message