lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Irwin <pir...@feature23.com>
Subject Re: Porting guidance
Date Sun, 20 Apr 2014 14:21:14 GMT
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 <itamar@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 <
> mherndon@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 <itamar@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: pirwin@feature23.com
Cell: 863-698-9294

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message