[
https://issues.apache.org/jira/browse/SOLR-11754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16288416#comment-16288416
]
Shawn Heisey commented on SOLR-11754:
-------------------------------------
It certainly does seem that there's almost nothing there. What little is there
that has function can probably be added to SolrTestCaseJ4. Looking over the
code, I don't even see any evidence that the class does what the javadoc says
it does, which is creating/destroying the index, and providing assertion
methods.
I guess the only question really becomes whether or not the abstraction itself
makes it easier for people to mentally grasp the test architecture. I don't
have a problem with shim classes that don't do very much, *if* their existence
and the name they've been given helps with understanding the code.
I do see AbstractZkTestCase as well, with far fewer descendants, but that
abstract class has a LOT more going on in it than the one you're proposing to
remove.
> Remove AbstractSolrTestCase
> ---------------------------
>
> Key: SOLR-11754
> URL: https://issues.apache.org/jira/browse/SOLR-11754
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
> Reporter: David Smiley
> Assignee: David Smiley
>
> I'm arguing AbstractSolrTestCase should be removed as it's obsoleted by
> SolrTestCaseJ4.
> In SOLR-3911 (back in 2012) Mark made it extend from SolrTestCaseJ4. There
> is really very little in this test class. Some of the methods here are
> duplicated by SolrTestCaseJ4 and thus are completely redundant
> (ignoreException, resetExceptionIgnores, getFile). There haven't been any
> modifications to this class of substance since 2012 either.
> I think we can just outright remove it (no deprecation phase). Anyone still
> using it can trivially switch.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
