I like Itamar's idea of porting the tests with the least amount of friction as possible. I also had Michael's concerns about carrotsearch but didn't get anywhere down that path.
On Sun, Apr 20, 2014 at 6:43 AM, Itamar Syn-Hershko <ita...@code972.com>wrote: > I'm not looking to duplicate the test framework itself line by line, but I > do want us to be able to copy-paste Lucene test classes and be able to > mostly just compile them and run. > > This is definitely doable, it just requires us to build a proper test > framework with all the supporting code and infrastructure. If NUnit limits > us and other test frameworks (xUnit?) can help us moving forward (or even > if they're just faster as far as I'm concerned), let's do the move. My > thinking was NUnit was closer to JUnit by design what will make the porting > easier but that's apparently not the case. > > I used extension methods to camel-case common methods like toString() and > equals(), again just to provide faster way of porting test classes. If > someone uses the test framework to test his own stuff he won't need it at > all. And as I said - our first priority at the moment needs to be > streamlining the porting process. > > I already have 2-3 test fixtures ported and passing using the methods I'm > trying to sell here. The process was pretty much effortless. > > Again, I will focus on the core lib and treat the testing lib as a sanity > check for the porting work, and once we have ported all core code and tests > focus on making the test framework usable. No point in overthinking this > now IMO. > > -- > > Itamar Syn-Hershko > http://code972.com | @synhershko <https://twitter.com/synhershko> > Freelance Developer & Consultant > Author of RavenDB in Action <http://manning.com/synhershko/> > > > On Sun, Apr 20, 2014 at 1:30 PM, michael herndon < > mhern...@michaelherndon.com> wrote: > > > 1. All code ported to the test-framework should NOT be standardized to > C#. > > For example this from Michael's recent commit: > > > > > https://github.com/apache/lucene.net/commit/23d1c0ac8604157b5975db4a8b34ac388b67c982#diff-1c97ea7db55add0d01e3b62d13df70d5R409 > > > > We should just use rarely() and newDirectory() and so on, this will allow > > us to just copy-paste tests that are using this (a lot!) without doing > > anything fancy with them. > > > > ------------------------------------- > > > > There will not be a complete 1 to 1 parity for the testing lib. JUnit > > currently allows greater flexibility than the current .NET unit testing > > frameworks. It allows you to create your own custom runners which is how > > carrotsearch randomization library is leveraged in Lucene. NUnit 3 may > > include similar functionality in the future. At the moment, it will > require > > some creative workarounds to produce similar functionality. > > > > Also I wouldn't camel case methods that already exist like ToString & > > Equals The testing framework was meant to enable developers to write > > tests for their applications and 3rd party libraries. At least that is > > what it was sold as at lucene revolution a few years back. There might > be a > > need to create an additional helper assembly meant for only the internal > > project tests. > > > > My current goal is to just get 3 test fixtures compile and pass test. > > After that, I'll write the same 3 test cases using F# and Vb.Net. It > will > > be a PITA, but that will give us three things: > > > > * Examples of how to write tests using different languages. > > * The ability to test Java compatibility changes for things that might > > prevent others from using the testing framework. > > * A chance to record the Java language and tooling differences. > > > > Thoughts? > > > > > > > > > > On Sun, Apr 20, 2014 at 1:44 AM, Itamar Syn-Hershko <ita...@code972.com > > >wrote: > > > > > Hi all, > > > > > > I've been going in a route that should allow us to port tests very > > easily, > > > I'd like to document the idea here and possibly have it made as > standard. > > > > > > It's been long decided that we will be .NET-ifying the API by pascal > > casing > > > names, converting setter/getter methods to properties (auto props where > > > possible), using Linq and yields instead of Java iterators etc. I think > > > there's still a lot of work to do there but that's for later. > > > > > > The thing is we don't really want to have all this maintenance work for > > > tests as well. Ideally, we should be copy-pasting test classes, run a > > quick > > > command line tool / Visual Studio plugin / R# plugin to normalize a few > > > bits and then run the test. > > > > > > The idea is to remove friction and non-important tasks from porting > work. > > > While it does make a lot of sense to have a .NET-compatible API for the > > > library itself, we simply don't care about pascal casing for test > classes > > > (or methods), nor do we care about the actual syntax there. As long as > it > > > compiles, works and tests our code - I'm good with that! > > > > > > So this is what I'm aiming for: > > > > > > 1. Support classes and methods in the test framework so we can compile > > Java > > > syntax. For example see: > > > > > > > > > https://github.com/apache/lucene.net/blob/branch_4x/test/test-framework/JavaCompatibility/SystemTypesHelpers.cs > > > > > > 2. A R# plugin I'm working on with a friend that is based on Paul > Irwin's > > > library that will C#-standardize everything which cannot be compiled > > > (pascal casing, getter/setter to properties, remove throws > declarations, > > > etc). Since this uses reflection it will work pretty nicely. This > should > > > resolve 99% of the rest of the compilation issues. > > > > > > 3. Copy pasting of Java Lucene test classes should now (mostly) just > > work. > > > > > > 4. We can maintain test classes by automated scripts that detect git > > > changes etc. This will allow us to dedicate most of our resources to > > actual > > > library porting > > > > > > I'll be happy to hear your opinions, but assuming we agree on the > above, > > > here are the action items for moving forward: > > > > > > 1. All code ported to the test-framework should NOT be standardized to > > C#. > > > For example this from Michael's recent commit: > > > > > > > > > https://github.com/apache/lucene.net/commit/23d1c0ac8604157b5975db4a8b34ac388b67c982#diff-1c97ea7db55add0d01e3b62d13df70d5R409 > > > > > > We should just use rarely() and newDirectory() and so on, this will > allow > > > us to just copy-paste tests that are using this (a lot!) without doing > > > anything fancy with them. > > > > > > 2. Since most of the tests are currently commented out / not included > in > > > the project, we should start bringing them in again using the > > > aforementioned process. The end result should be all Java test classes > as > > > compiled C# ones against Lucene.NET. There's a lot of infrasturcture > > > missing too, like the randomized testing Michael has started porting. > > > > > > 3. Integrating with a CI server, Travis for instance offers hosting for > > > free. This means we get to test our compilation on Mono, too! > > > > > > That's it for now - let me know your thoughts > > > > > > -- > > > > > > Itamar Syn-Hershko > > > http://code972.com | @synhershko <https://twitter.com/synhershko> > > > Freelance Developer & Consultant > > > Author of RavenDB in Action <http://manning.com/synhershko/> > > > > > > -- Paul Irwin Lead Software Engineer feature[23] Email: pir...@feature23.com Cell: 863-698-9294
