lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Itamar Syn-Hershko <ita...@code972.com>
Subject Re: Porting guidance
Date Sun, 20 Apr 2014 10:43:14 GMT
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/>
> >
>

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