Erick, I certainly mean for this to be committed prior to a 4.1 (possibly it should be a Blocker), and if you want to commit, then go ahead. My only concern is that if it gets committed without test coverage that a new issue be opened to add a test later.
I'm tired of breaking DIH every time I commit a change because the test coverage was inadequate and I was lulled into a false sense of security by "All Tests Pass". ZKPropertiesWriter is a case in point. This was committed back in February with no test coverage and then I come along and break it in November. I've been trying lately to write better tests for DIH but if people's attitude is "DIH is a low-quality contrib mod...I don't need to write a test", then what's the point? (we all have stories about working with developers who created "negative productivity". I'm trying to personally stay out of anyone's story like that here!) Then again my concern about coverage shouldn't hold this hostage so it misses the next release.
I also wonder if
SOLR-3911 means changing how ZKPropertiesWriter works entirely, or if it is even necessary at all? I don't know enough about SolrCloud (yet...its on my to-do list) to understand how SOLR-3911 might change what needs to be done here, but maybe there is a different, better approach now?
Mark, you said something about setting up a base test class to build on, but I was just looking at AbstrackDistribZKTestCase and isn't such a base class already there? Isn't all we need to do is to set up a 1-node, 1-shard "cluster" and have it import 1 document then open the Properties file with ZKPropertiesWriter and see if it exists and can be read? Someday we can get fancy and expand TestSqlEntityProcessorDelta to sometimes run in full distributed mode but for now something quick and simple would suffice, right?