On 12/2/2014 10:47 PM, Michael Wechner wrote: > I think you are right that in certain cases, like for example in the > case of CompressingStoredFieldsFormat > it makes a lot of sense to run the entire test suit (even multiple times > considering randomization), but I would argue that there are probably > quite a few other cases where incremental testing would be sufficient, > at least as a first shot.
I do like to run the entire test suite at least once before I commit a change. Usually I don't work on pieces of the system that are quite this central ... At my current skill level, I am more comfortable at the edges, where the code that I write is not expected to hold up huge sections of the entire project. Knowing what tests to run during development of a particular bugfix or change (when you definitely don't want to wait for the whole test suite) is something that comes with a lot of experience. I will often resort to asking dumb questions in Jira or on this list. Writing a new test for the specific feature or problem you're working on is something we definitely encourage. Later review might find that it's redundant and one of them might get removed, but a lengthy test suite is a small price to pay for code that can be trusted. With IDE tools like Eclipse or Idea, you can trace the derivation and usage of each class, which can give you hints about which tests might be appropriate, but the interconnections can quickly become too complicated to track. Every time I go diving into the source code, I am impressed and daunted by the complex web of inheritance and interdependence that Lucene/Solr contains. From what I've seen, our codebase makes effective use of just about every capability that Java offers. Thanks, Shawn --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
