> On 29 Apr 2015, at 17:07, Alexander Shorin <[email protected]> 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 <[email protected]> wrote: >> Sounds sensible to me :) >> >> Good job there! >> >> Best >> Jan >> -- >> >>> On 13 Jan 2015, at 19:24 , Alexander Shorin <[email protected]> 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/
