[
https://issues.apache.org/jira/browse/SOLR-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510471#comment-13510471
]
Per Steffensen edited comment on SOLR-4114 at 12/5/12 1:47 PM:
---------------------------------------------------------------
Guess there are two "movements" in the industry at the moment
* TDD: Mostly focused at testing "units" (single components), hoping that if
all "units" work as they are supposed to, the entire system where all those
"units" are used in combination will also work as it is supposed to
* BDD: Mostly focused at testing "behaviour" of a system seen from the outside,
because that is basically all you care about. No one cares how the system works
internally. Everyone cares about how the system works as a whole, when used to
the extend you can use it "from the outside". This is especially true for the
end users of the system, and at the end of the day a system is created to
fullfil the users needs.
bq. Integration-level tests aren't nearly as useful
I completely disagree with that.
I, personally, are not that much into "unit"-tests because thay basically do
not show that the system as a whole "behaves" as it is supposed to.
Behavioural/integration-tests does, where you test against an entire system
using it the way it can be used "from the outside", and asserting that "result"
is as expected seen "from the outside".
bq. and much more difficult to debug
You are right about that. I like "unit"-tests to supplement
behavioural/integration-tests whenever it is found to be necessary. We can add
a OverseerCollectionProcessor "unit"-test, testing some of this new
functionality, but in my mind (as I said) "it will not ensure the correct
system-level functionality to nearly the same degree", and basically thats all
we are interrested in.
If the community would like we can supplement with "unit"-tests for this new
feature, but you will have to fight me (FWIW) to get rid of the integration-ish
test of the feature.
was (Author: steff1193):
Guess there are two "movements" in the industry at the moment
* TDD: Mostly focused at testing "units" (single components), hoping that if
all "units" work as they are supposed to, the entire system where all those
"units" are used in combination will also work as it is supposed to
* BDD: Mostly focused at testing "behaviour" of a system seen from the outside,
because that is basically all you care about. No one cares how the system works
internally. Everyone cares about how the system works as a whole, when used to
the extend you can use it "from the outside". This is especially true for the
end users of the system, and at the end of the day a system is created to
fullfil the users needs.
bq. Integration-level tests aren't nearly as useful
I completely disagree with that.
I, personally, are not that much into "unit"-tests because thay basically do
not show that the system as a whole "behaves" as it is supposed to.
Behavioural/integration-tests does, where you test against an entire system
using it the way it can be used "from the outside", and asserting that "result"
is as expected seen "from the outside".
bq. and much more difficult to debug
You are right about that. It like "unit"-tests to supplement
behavioural/integration-tests whenever it is found to be necessary. We can add
a OverseerCollectionProcessor "unit"-test, testing some of this new
functionality, but in my mind (as I said) "it will not ensure the correct
system-level functionality to nearly the same degree", and basically thats all
we are interrested in.
If the community would like we can supplement with "unit"-tests for this new
feature, but you will have to fight me (FWIW) to get rid of the integration-ish
test of the feature.
> Collection API: Allow multiple shards from one collection on the same Solr
> server
> ---------------------------------------------------------------------------------
>
> Key: SOLR-4114
> URL: https://issues.apache.org/jira/browse/SOLR-4114
> Project: Solr
> Issue Type: New Feature
> Components: multicore, SolrCloud
> Affects Versions: 4.0
> Environment: Solr 4.0.0 release
> Reporter: Per Steffensen
> Assignee: Per Steffensen
> Labels: collection-api, multicore, shard, shard-allocation
> Attachments: SOLR-4114.patch, SOLR-4114.patch, SOLR-4114.patch,
> SOLR-4114.patch, SOLR-4114_trunk.patch
>
>
> We should support running multiple shards from one collection on the same
> Solr server - the run a collection with 8 shards on a 4 Solr server cluster
> (each Solr server running 2 shards).
> Performance tests at our side has shown that this is a good idea, and it is
> also a good idea for easy elasticity later on - it is much easier to move an
> entire existing shards from one Solr server to another one that just joined
> the cluter than it is to split an exsiting shard among the Solr that used to
> run it and the new Solr.
> See dev mailing list discussion "Multiple shards for one collection on the
> same Solr server"
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
