[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] optimizers, tests and temp files

I usually use Easymock (http://www.easymock.org/) for creating mocks on the fly. Unfortunately we can not use Easymock 2.x because it requires generics support. With Easymock 2.x it is almost fun creating mocks. A version suitable for our environment is available at http://prdownloads.sourceforge.net/easymock/easymock1.2_Java1.3.zip
Is there a common interest in using a mock library?

Stefan


Jeff McAffer wrote:

Actually, Stefan had a good idea for mocking up repos so in the end I have not had to create artifact repos for ths optimizer tests.  Originally I had some "round trip" tests that optimized artifacts back into the repo and then fetched them again etc.  That was cool but in the end very messy and hard to manage.  Stefan's approach was cleaner and more focused on the "unit" that was being tested.  So I guess yes there was a tiny bit of infrastructure but nothing that could be abstracted (except for the approach)

To a certain degree I suspect that some of our other tests could benefit from this more focused approach to help simplify their creation, running and cleanup.  However there will in the end be a need for real repos etc.

As for cleaning up, yes, this agentdata area thing is a problem.  More generally we need to be very clear and simple about what goes where.  I'm not sure how to really address the problem in the code.

Jeff



Pascal Rapicault/Ottawa/IBM@IBMCA
Sent by: equinox-dev-bounces@xxxxxxxxxxx

11/12/2007 09:57 PM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc
equinox-dev@xxxxxxxxxxx, equinox-dev-bounces@xxxxxxxxxxx
Subject
Re: [equinox-dev] optimizers, tests and temp files







Failing tests that can't be fixed should be commented out and a bug report
should be opened. This is the policy that is used in other places.

I agree that tests should be cleaning up after themselves
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=209069) or at least make
sure that deleting the config folder put you back in a clean state. In the
framework admin tests I have taken the approach of storing files into
BundleContext.getDataFile and also using the test class name as a unique
token. Do we think this is enough?

Wrt to the TestMetadataRepository, I must admit that I'm a bit surprised by
the pollution it creates since it was supposed to be a in memory repo... I
have opened bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=209588

As part of your tests, did you end up creating helpers facilitating the
creation of artifact repo?

PaScaL



                                                                                                                           
 From:       Jeff McAffer/Ottawa/IBM@IBMCA                                                                                  
                                                                                                                           
 To:         equinox-dev@xxxxxxxxxxx                                                                                        
                                                                                                                           
 Date:       11/12/2007 08:54 PM                                                                                            
                                                                                                                           
 Subject:    [equinox-dev] optimizers, tests and temp files                                                                
                                                                                                                           






I just committed another refactoring of the repo optimizers along with an
improved version of the JarDelta optimizer and some basic tests.  We should
have well optimized repos now! (next step is to pack the jar deltas!!)

In runnig the tests before committing there appear to be 11 of the Director
tests failing.  I did not do anything in this area so assume that they were
failing before this new code came along?  What is our policy on failing
tests?  I've been commenting out my tests that fail until they can be
fixed.  Others?

A number of tests use the TestMetadataRepository mechanism.  This is cool
but unfortunately it leaves temp files down in Documents and Setting
(Windows) at a pretty high rate (~30 per full test run).  There are a few
other files being left around.  We should ensure that our tests run and
clean up after themselves.  In the optimizer tests I've taken to naming the
files and dirs something related to the name of the test (e.g.
p2.optimizers.xxx) so that people encountering these files (leftover from
crashed test runs etc) know what they are.  Do others think this to be a
good idea?

Related to this, we are all likely struggling to setup various repos etc
temporarily for tests and inevitiably using different approaches.  Would it
be worth spending a bit of time creating some test repo infrastructure,
documenting this on the wiki (or wherever) and then making the tests
consistent?  Most of the time I spend on this little project was in
managing all the test code and updating multiple copies.  Taht is, until I
refactored to eliminate duplicate code.  Now the test read well and are
very easy to create.  Easy to create tests => more tests => better code...
Thoughts?

Jeff_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev


_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev


_______________________________________________ equinox-dev mailing list equinox-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/equinox-dev