Document unit tests

[Ciaran Roarty]

Hi

 

I plan to continue working on the Document unit tests tonight - and learn how to merge and push the repo - is that ok? Don't want to duplicate effort but I've got a good version of the first test done and I think I can push through the rest of them.

 

Let me know,

Ciaran

[Sergey Mirvoda]

I've pushed Locks implementation and some LockFactory tests. 

I think its ok to push everything as early as possible.

--
You received this message because you are subscribed to the Google Groups "Lucere Development" group.
To post to this group, send email to lucer...@googlegroups.com.
To unsubscribe from this group, send email to lucere-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/lucere-dev?hl=en.

--
--Regards, Sergey Mirvoda

[Christopher Currens]

That's fine.  I don't have time to finish the unit tests on the Entity layer, which is why I wanted to commit and have someone else have a go at it.  I think the one thing we are not pushing is actual class implementation of the interfaces.  We want to get the interfaces worked out and looked over before we decide what implementation goes where and what's really necessary, at least that's my understanding of our project goals.

-Chris

[Sergey Mirvoda]

yes it is.

But Lucene Locks are special one.

It is not only interprocess but inter PCs locks.

Also you can copy pasting everywhere inheritors of ILockFactory (ISimpleLF:ILF, INoLF:ILF)

and all you will get is testing you mocks. For what?

Lucene Locks are all about file creatin\checking\deleting in all known and unknown special cases.

Locks are hard core programming especially in MT scenarios 

but mocks is a fake :) for testing Locks.

Although mocking Locks and LockFactory are useful and must have for TDD.

I've googletalked with Troy about this.

Locks are single independent part of 

Luce[ne|re]

and all other parts directly or indirectly depends on it.

as for future refactoring.

What can you refactor in such an interface?

interface ILock

{

   bool Obtain()

   void Release()

   bool IsExist()

}

interface ILockFactory

{

   MakeLock(string)

   ClearLock(string )  //could be AbortLock 

[Sergey Mirvoda]

also i'm very strong CI believer with its best slogan:

Do the most little thing that works.

I'm sure we should implement Lucene 3.0.2 and then move on towards FULL .NET look and feel.

btw

For NH it takes 3 versions to forget about Hibernate.

--
--Regards, Sergey Mirvoda

[Christopher Currens]

With regards to refactoring the locks interface, I suppose it's less
refactoring and more re-thinking, which is the real goal of this
project anyway. I'm getting that either people don't have the same
goals as I read them outlined in the "Plan Of Action" thread, or that
I apparently don't understand them. I'm not at all disagreeing we
should have a working build of 3.0.2 before we move forward on a large-
scale refactoring, it's stated we should do that in the project's road
map. However, in this first phase, we are doing minor ".netifying",
taking that minimalistic approach.

I don't think implementing locks was a bad thing to do, per se,
however my fear is that other developers would see that it was done
and think they're expected to get implementations done on the
namespaces they're working on. It could possibly slow us down, cause
confusion, etc, if people didn't understand they aren't expected to
complete implementation until the Contracts and Tests stage is done.
Even still, at this early stage, it may also be a benefit for our
future refactoring efforts if we were to reorganize the interfaces
into other, possibly even new, namespaces. I think we can all agree
that the current version of Lucene is very crowded in areas and
reorganizing wouldn't cause any major headaches in implementing the
classes in Stage Two.

Just some thoughts. If half of us agree with me, and the other half
still don't, maybe we should discuss the project goals again?

Christopher

> >>> On Thu, Nov 18, 2010 at 10:21 PM, Ciaran Roarty <ciaran.roa...@gmail.com

> >>> > wrote:
>
> >>>> Hi
>
> >>>> I plan to continue working on the Document unit tests tonight - and
> >>>> learn how to merge and push the repo - is that ok? Don't want to duplicate
> >>>> effort but I've got a good version of the first test done and I think I can
> >>>> push through the rest of them.
>
> >>>> Let me know,
> >>>> Ciaran
>
> >>>> --
> >>>> You received this message because you are subscribed to the Google
> >>>> Groups "Lucere Development" group.
> >>>> To post to this group, send email to lucer...@googlegroups.com.
> >>>> To unsubscribe from this group, send email to

> >>>> lucere-dev+...@googlegroups.com<lucere-dev%2Bunsubscribe@googlegrou ps.com>
> >>>> .

> >>>> For more options, visit this group at
> >>>>http://groups.google.com/group/lucere-dev?hl=en.
>
> >>> --
> >>> --Regards, Sergey Mirvoda
>
> >>> --
> >>> You received this message because you are subscribed to the Google Groups
> >>> "Lucere Development" group.
> >>> To post to this group, send email to lucer...@googlegroups.com.
> >>> To unsubscribe from this group, send email to

> >>> lucere-dev+...@googlegroups.com<lucere-dev%2Bunsubscribe@googlegrou ps.com>
> >>> .

> >>> For more options, visit this group at
> >>>http://groups.google.com/group/lucere-dev?hl=en.
>
> >>  --
> >> You received this message because you are subscribed to the Google Groups
> >> "Lucere Development" group.
> >> To post to this group, send email to lucer...@googlegroups.com.
> >> To unsubscribe from this group, send email to

> >> lucere-dev+...@googlegroups.com<lucere-dev%2Bunsubscribe@googlegrou ps.com>
> >> .

[Troy Howard]

I have four main reasons for wanting to defer implementation until
after the contracts (interfaces) and tests have been written:

1. It's the only way to possibly meet the time schedule outlined.
Implementations will take too long if done serially.

2. Refactoring against the interfaces alone can be done faster and
more flexibly if we don't need to update existing implementations
during the refactoring.

3. In theory, porting will be easier under the refactored contracts
than under the Java contracts as many of the structural elements of
the Java code don't really make much sense in .NET causing greater
porting impedance.

4, I like TDD and this is how TDD works. ;)

That said, the work Sergey and Mark have already done to implement the
classes in lucere.io/lucere.io.concurrency is not wasted effort. We
can hang on to those implementations until we reach Stage 2. Notably,
those are the first classes we'll need to implement, so we've got a
head-start on Stage 2 when we get to it.

I'd like to see mocks for those classes as part of the unit tests
however and see the unit tests refactored to work against the mocks
for now (even if the class is fully implemented and passing the
tests). This is to facilitate reason #2 listed above.

Thanks,
Troy

> To unsubscribe from this group, send email to lucere-dev+...@googlegroups.com.

[Sergey Mirvoda]

@Troy

I'm completely with you.

Now working on hand written mocks for Locking.

Extracting interfaces from all ILock and ILockFactory implementayions is only thing to do 

to complete concurrency definition and with Resharper goodness is easy as hell.

What is the next thing to do?

The wiki list still empty! 

It is very unlikely for to waste free time doing other guys work.

--
--Regards, Sergey Mirvoda

[Sergey Mirvoda]

just removed io implementation.

All concurrency is done and pushed.

Tests are waiting IO to complete by Mark.

Can I take Service Layer part?

anybody working on it?

--
--Regards, Sergey Mirvoda

[Ciaran Roarty]

Got a bit mixed up with commits and merges locally but everything seems to have made it up; will continue the Document tests tomorrow ( today, as I’ve just noticed it is 00:32).

 

C