lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From michael herndon <mhern...@michaelherndon.com>
Subject Re: Porting guidance
Date Sun, 20 Apr 2014 10:30:55 GMT
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