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 16:24:46 GMT
Its no longer just an NUnit limitation. As far as I know,  it is limitation
for current .NET unit testing frameworks.

The .Net testing frameworks, mbunit, xunit, nunit generally have a test
framework library which is extensible. They also have a separate
librar(y|ies) for executing tests which is limited in extensibility.

JUnit lets you swap out the runner by annotating a custom test runner in
your testing library.  It also allows you to define your rules for how
things are executed in a rule chain.  This way you can change execution and
still have it run within eclipse without changing the test runner add in.

You can think of it as unit testing middleware.
http://junit.org/javadoc/4.11/org/junit/rules/RuleChain.html

.NET testing frameworks are not designed to do this.  If you want to swap
out the test runner, you either fork the project or create your own test
runner like the ReSharper test runner.

-M




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/>
> > >
> >
>

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