automated testing

[Victor Mote <vi...@outfitr.com>]

FOP Developers:

I am readying the first installment of the font refactoring work, and am
wanting to make all reasonable efforts to make sure that this work doesn't
break anything. I have the following questions about the automated testing:

1. The W3C tests are for standards compliance as opposed to regression
testing. Am I correct in assuming that they are not relevant for the work I
am doing? Or is it SOP to regression test against these as well?

2. Out of the box, the build.xml wants FOP 0.20.3. Since I am testing
against some baseline jar file (I was planning on testing against the
current maintenance branch cvs), is it OK to simply change the build.xml to
the correct version, or am I missing something here?

Victor Mote


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

RE: automated testing

[Keiron Liddle <ke...@aftexsw.com>]

On Wed, 2002-10-23 at 17:08, Victor Mote wrote:
> I am not sure I understand your question. My current plan is to do the
> refactoring on the maintenance branch, then bring it over to trunk when
> complete. Otherwise, I am going to have difficulty testing it. If you are
> asking whether the refactoring will be done on a branch from the maintenance
> branch, that has not been discussed, but I have no objection to it, and it
> might make things cleaner with the 0.20.5 release on the horizon.

It is just that I have done some things with the FontState and FontInfo
on trunk. You may want to take a look at that. The font-weight is a
number and it uses a string key to specify the font for serialization.
But there is a lot more to do.

> > I doubt the tests would check much beyond the basic fonts, I suppose it
> > depends what you are going to change.
> 
> My intention is to try to consolidate all of the font classes that are
> floating around into a handful of more intuitive classes. For example, the
> first installment eliminates the layout.FontInfo class and moves its
> contents into static fields in new font.TypeFace and font.TypeFaceFamily
> classes. Future installments will move almost all of layout.FontState into
> font.FOPFont (or possibly font.Font), protect most of its innards, and
> provide methods for working with those innards. (FontState has a
> _letterSpacing field which, as far as I can tell, is outside of a Font
> concept, so FontState will need to exist until I can find a better home for
> that.) I also think most of the font-specific stuff that is in the render
> package can be consolidated and simplified (and moved), but I haven't
> grasped all of what is going on there yet. The ultimate purpose is to make
> it easier to 1) follow what is going on, 2) add support for other font
> sources, including OpenType and fonts registered at the OS level. In
> general, I am trying to address some of what you wrote in your July 18 post
> on this subject, as well as some of my own ideas.

That sounds like a good approach.
I particularly like the "make it easier to follow what is going on".

> Understood. Since I am going to be doing a fair amount of refactoring, does
> it make sense for me to stop & work on the testing first, or do we generally
> prefer to "field test"?

I think the "field test" is the best for now. It would probably be a
waste of effort sorting out the testing now.

If possible it might be better if some of these areas could have unit
testing rather than relying on the system testing.

> BTW, it is good to "hear your voice" again.

Thanks.

When these fonts things a sorted out it will be really good. So it is
good to see you working on it.

Keiron.



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

RE: automated testing

[Victor Mote <vi...@outfitr.com>]

Keiron Liddle wrote:

> Is this refactoring on branch? (I've probably missed some important
> discussion so bear with me :)

I am not sure I understand your question. My current plan is to do the
refactoring on the maintenance branch, then bring it over to trunk when
complete. Otherwise, I am going to have difficulty testing it. If you are
asking whether the refactoring will be done on a branch from the maintenance
branch, that has not been discussed, but I have no objection to it, and it
might make things cleaner with the 0.20.5 release on the horizon.

> I doubt the tests would check much beyond the basic fonts, I suppose it
> depends what you are going to change.

My intention is to try to consolidate all of the font classes that are
floating around into a handful of more intuitive classes. For example, the
first installment eliminates the layout.FontInfo class and moves its
contents into static fields in new font.TypeFace and font.TypeFaceFamily
classes. Future installments will move almost all of layout.FontState into
font.FOPFont (or possibly font.Font), protect most of its innards, and
provide methods for working with those innards. (FontState has a
_letterSpacing field which, as far as I can tell, is outside of a Font
concept, so FontState will need to exist until I can find a better home for
that.) I also think most of the font-specific stuff that is in the render
package can be consolidated and simplified (and moved), but I haven't
grasped all of what is going on there yet. The ultimate purpose is to make
it easier to 1) follow what is going on, 2) add support for other font
sources, including OpenType and fonts registered at the OS level. In
general, I am trying to address some of what you wrote in your July 18 post
on this subject, as well as some of my own ideas.

> The idea is that the tests are run against a version with an expected
> result. If the new output is different and the test passed before then
> there is a problem. This hasn't really been setup properly yet.

Understood. Since I am going to be doing a fair amount of refactoring, does
it make sense for me to stop & work on the testing first, or do we generally
prefer to "field test"?

BTW, it is good to "hear your voice" again.

Victor Mote


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: automated testing

[Keiron Liddle <ke...@aftexsw.com>]

On Wed, 2002-10-23 at 16:00, Victor Mote wrote:
> FOP Developers:
> 
> I am readying the first installment of the font refactoring work, and am
> wanting to make all reasonable efforts to make sure that this work doesn't
> break anything. I have the following questions about the automated testing:

Is this refactoring on branch? (I've probably missed some important
discussion so bear with me :)

> 1. The W3C tests are for standards compliance as opposed to regression
> testing. Am I correct in assuming that they are not relevant for the work I
> am doing? Or is it SOP to regression test against these as well?

Yes the w3c tests are for standards compliance but in theory it could be
used for regression testing if it was setup.
So far things have been moving to much to be able to develop the testing
any further.
I doubt the tests would check much beyond the basic fonts, I suppose it
depends what you are going to change.

> 2. Out of the box, the build.xml wants FOP 0.20.3. Since I am testing
> against some baseline jar file (I was planning on testing against the
> current maintenance branch cvs), is it OK to simply change the build.xml to
> the correct version, or am I missing something here?

The idea is that the tests are run against a version with an expected
result. If the new output is different and the test passed before then
there is a problem. This hasn't really been setup properly yet.

> Victor Mote



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org