gerlowskija commented on code in PR #1053: URL: https://github.com/apache/solr/pull/1053#discussion_r1006192774
########## solr/core/src/test/org/apache/solr/handler/admin/api/DeleteReplicaPropertyAPITest.java: ########## @@ -0,0 +1,116 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +package org.apache.solr.handler.admin.api; + +import static org.apache.solr.cloud.api.collections.CollectionHandlingUtils.SHARD_UNIQUE; +import static org.mockito.ArgumentMatchers.any; +import static org.mockito.ArgumentMatchers.anyLong; +import static org.mockito.Mockito.mock; +import static org.mockito.Mockito.verify; +import static org.mockito.Mockito.when; + +import io.opentracing.noop.NoopSpan; +import java.util.Map; +import java.util.Optional; +import org.apache.solr.SolrTestCaseJ4; +import org.apache.solr.cloud.OverseerSolrResponse; +import org.apache.solr.cloud.api.collections.DistributedCollectionConfigSetCommandRunner; +import org.apache.solr.common.SolrException; +import org.apache.solr.common.cloud.ZkNodeProps; +import org.apache.solr.common.util.NamedList; +import org.apache.solr.core.CoreContainer; +import org.apache.solr.request.SolrQueryRequest; +import org.apache.solr.response.SolrQueryResponse; +import org.junit.Before; +import org.junit.BeforeClass; +import org.junit.Test; +import org.mockito.ArgumentCaptor; + +/** Unit tests for {@link DeleteReplicaPropertyAPI} */ +public class DeleteReplicaPropertyAPITest extends SolrTestCaseJ4 { + + private CoreContainer mockCoreContainer; + private DistributedCollectionConfigSetCommandRunner mockCommandRunner; + private SolrQueryRequest mockQueryRequest; + private SolrQueryResponse queryResponse; + private ArgumentCaptor<ZkNodeProps> messageCapturer; + + private DeleteReplicaPropertyAPI deleteReplicaPropApi; + + @BeforeClass + public static void ensureWorkingMockito() { + assumeWorkingMockito(); + } + + @Before + public void setUp() throws Exception { + super.setUp(); + + mockCoreContainer = mock(CoreContainer.class); + mockCommandRunner = mock(DistributedCollectionConfigSetCommandRunner.class); + when(mockCoreContainer.getDistributedCollectionCommandRunner()) + .thenReturn(Optional.of(mockCommandRunner)); + when(mockCommandRunner.runCollectionCommand(any(), any(), anyLong())) + .thenReturn(new OverseerSolrResponse(new NamedList<>())); + mockQueryRequest = mock(SolrQueryRequest.class); + when(mockQueryRequest.getSpan()).thenReturn(NoopSpan.INSTANCE); Review Comment: Sorry for the delay replying here: Mocking can be awkward for sure. You're not wrong. But IMO most of the time when mocking is ugly or when it has to reference obscure unrelated things - it's a sign that the code-under-test is designed poorly. e.g. We only have to muck about with NoopSpan here because the API logic itself in CollectionsHandler mucks about with spans (albeit indirectly, through `o.a.s.util.tracing.TracingUtils`). I'm sure there's good reason for it to be where it is, but If tracing stuff was off in a Jetty servlet filter (or where ever) this test probably _would_ have no mention of it. I guess I'm not claiming that mocks are ideal, but I see them as a huge improvement (or at least, a badly needed supplement) to some of our other testing patterns. We're going on a decade now of serious flakiness and speed concerns in our test suite! And I think our communal aversion to anything that's _not_ an end-to-end test plays a big role there. Spinning up full SolrCloud+ZK clusters is normal! Our "light" option still spins up 1 or more full Jetty servers! Talk about bringing in obscure, unrelated things! > If we need mocking, could we have test helpers/shims/subclasses such that the Mocking we need are pertinent to what it is being tested I can try abstracting some of this out into a helper or subclass, but my guess is that it might only have limited applicability. v2 APIs that we pull out of CollectionsHandler will be able to use it, sure, but does the logic in e.g. ConfigSetsHandler interact with tracing in quite the same way? Idk. Another alternative, if you still find the mocks repellent, would be to extract the "message creation" piece into a class that can be separately unit-tested without needing mocks. That's essentially what these tests are validating, that the RPC message triggered by a given API call looks the way it should. Or we could go a different route and do something that extends `JerseyTest`, though if I remember right you had other reasons for disliking that approach? So I guess there's 3 options there: (1) hide the mocks behind utils/parent-classes, (2) mockless unit testing on the message-creation logic only, or (3) something JerseyTest-based with hopefully fewer mocks. Any of those jump out at you as preferable @dsmiley ? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
