You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Alexander Shorin <kx...@gmail.com> on 2015/04/29 17:07:30 UTC

Re: [PROPOSAL] CouchDB tests organization

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 <ja...@apache.org> wrote:
> Sounds sensible to me :)
>
> Good job there!
>
> Best
> Jan
> --
>
>> On 13 Jan 2015, at 19:24 , Alexander Shorin <kx...@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?
>>
>> --
>> ,,,^..^,,,
>

Re: [PROPOSAL] CouchDB tests organization

Posted by Jan Lehnardt <ja...@apache.org>.
+1

> On 29 Apr 2015, at 17:48, Alexander Shorin <kx...@gmail.com> wrote:
> 
> On Wed, Apr 29, 2015 at 6:28 PM, Jan Lehnardt <ja...@apache.org> wrote:
>>> On 29 Apr 2015, at 17:07, Alexander Shorin <kx...@gmail.com> wrote:
>>> 
>>> 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?
>> 
>> Feel free to go at it! :)
>> 
>> We might want to cherry-pick a few things from https://github.com/pouchdb/couchdb-harness
>> which is the PouchDB team doing the extraction for us :)
> 
> Good idea!  I'll request then for now two repos: couchdb-erlang-tests
> and couchdb-javascript-tests
> 
> --
> ,,,^..^,,,

-- 
Professional Support for Apache CouchDB:
http://www.neighbourhood.ie/couchdb-support/


Re: [PROPOSAL] CouchDB tests organization

Posted by Alexander Shorin <kx...@gmail.com>.
On Wed, Apr 29, 2015 at 6:28 PM, Jan Lehnardt <ja...@apache.org> wrote:
>> On 29 Apr 2015, at 17:07, Alexander Shorin <kx...@gmail.com> wrote:
>>
>> 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?
>
> Feel free to go at it! :)
>
> We might want to cherry-pick a few things from https://github.com/pouchdb/couchdb-harness
> which is the PouchDB team doing the extraction for us :)

Good idea!  I'll request then for now two repos: couchdb-erlang-tests
and couchdb-javascript-tests

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

Re: [PROPOSAL] CouchDB tests organization

Posted by Jan Lehnardt <ja...@apache.org>.
> On 29 Apr 2015, at 17:07, Alexander Shorin <kx...@gmail.com> wrote:
> 
> 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?

Feel free to go at it! :)

We might want to cherry-pick a few things from https://github.com/pouchdb/couchdb-harness
which is the PouchDB team doing the extraction for us :)

Best
Jan
--

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

-- 
Professional Support for Apache CouchDB:
http://www.neighbourhood.ie/couchdb-support/