Re: [gui-dev] [tests] remaining code coverage and failures (bad assumptions on old code behavior)

Hi Philippe,

Yes, the tests were failing for quite a while.  The tests on Windows 
are failing more than on OSX because those tests are using a different 
version of Clover.  The version they're using writes files out in a 
different format, one that is causes a few other tests to fail.  We 
haven't had a chance to clean that up yet.

We ideally would have the test suite run without requiring full 
internet access.  If some tests are failing because of that, we should 
look into the code to see why the access is required.  Things like 
alternate locations should ideally not require inet access just to be 
constructed -- if they do, that should be fixed.  If you would like to 
provide patches for that, that'd be great.

Thanks,
  Sam

On Mar 3, 2005, at 4:04 PM, Philippe Verdy wrote:

> I have just seen that the automated Junit tests with Clover have
> regained high levels of success.
> But there still remains some failures that persist since long. Although
> I don't think they are actually bugs in Limewire core's (I think that
> they are bad assumptions that remain in the tests modules themselves),
> I think that increasing the test coverage rate would really help now,
> because the core structure is now stable in those remaining persistent
> "bugging" areas.
>
> Before we go into changing some structure of the core itself, it would
> be good to close all those test failures, and maximizing our code
> coverage in tests (notably in the downloader, in UDP support, and in
> XML meta-data processing).
>
> The tests currently have the best results on MacOSX, then on Windows XP
> with Java 1.5, but XP with Java 1.4 is still the predominent platform
> for Limewire, and it has the lowest code coverage rate...
>
> Is there a way to help there?
>
> -----------
>
> Another thing: I would really like to be able to perform all the tests
> in offline mode, without being connected to the Internet. The only
> thing that forbids me to complete the whole tests suite is that there
> is a small list of domain names which must be resolvable with local DNS
> client, but we actullay don't care about which IP they resolve to. So,
> is there a way to tune the DNS resolver used in LimeWire, so that it
> will resolve them in a local static cache as if there was a "hosts"
> file, i.e. without performing actual DNS requests on the DNS server of
> my ISP.
>
> This list is not extremely long, and may be these tests could reuse a
> more limited number of domain names, that would resolve in an area only
> used for LimeWire tests (for example, we do need to resolve
> www.cnn.com, or www.google.com, but I hate having to leave permanent
> entries for these domain names in my host file: in addition, my
> anti-adware tool persists in removing these manual entries becuase it
> thinks that, despite their value is correct, they may be hijackers).
>
> Is there a way to feed the DNS client JAR library used by Limewire with
> such list before launching tests that depend on these domain names?
> could we change them to more immune subdomian names within a
> ".tests.limewire.org" domain, that we could remap locally with a single
> wildcard entry in our local DNS client cache? This way these domain
> names could remain permanently in our local host file, and this would
> not block regular accesses to the websites indicated (such as
> google.com, or w3.org, or limewire.com that I consult often).
>
>
>
> =====
>
>
>
> 	
>
> 	
> 		
> Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour 
> vos mails !
> Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/
> _______________________________________________
> gui-dev mailing list
> [email protected]
> http://www.limewire.org/mailman/listinfo/gui-dev
>


_______________________________________________
gui-dev mailing list
[email protected]
http://www.limewire.org/mailman/listinfo/gui-dev