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/01/13 19:24:31 UTC
[PROPOSAL] CouchDB tests organization
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/
Re: [PROPOSAL] CouchDB tests organization
Posted by Alexander Shorin <kx...@gmail.com>.
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>.
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?
>
> --
> ,,,^..^,,,