From: Tom E. <to...@jb...> - 2005-11-02 06:14:37
|
There are two issues: 1. Project B has proper test coverage (within its own project) 2. Project A detecting there is a hole in project B's test coverage For issue 1, I agree with all that everyone is saying. The only exception would be that a developer from A should write test cases for project B to ensure complete coverage. Although that would be great, it just simply isn't going to happen (for various reason, which I can enumerate if need be). The best we can hope for is that they open a jira issue for it. Issue 2, and what I was originally talking about, is about early visibility to project B's test coverage holes. If A is only testing against released versions of B, will not know about the hole till too late (after the next release of B). If A is testing against a development snapshot of B, would be able to detect and plug a hole earlier in the development cycle of B (probably via a opening a jira issue). Scott M Stark wrote: > The basic tests for the contracts need to live in B though or else the > feedback loop for discrepency is too disconnected, and its the B project > that has to agree what the supported integration interfaces are. This is > exactly the problem with ejb3 integration today where there is zero > agreement on how the ejb3 deployer behaves as a pluggable component into > jbossas. > > > >>-----Original Message----- >>From: jbo...@li... >>[mailto:jbo...@li...] On >>Behalf Of Tom Elrod >>Sent: Tuesday, November 01, 2005 9:08 AM >>To: jbo...@li... >>Subject: Re: [JBoss-dev] Integration issues >> >>I think we are making this more complicated than it needs to >>be. To me, the solution is simple. >> >>Project A will have a testsuite to make sure that it works. >>Project B will have at least two versions; stable (released) >>and development (snapshot). Project A should have automated >>testsuite run against stable and development version of B. >> >>Is the responsibility of A to make sure tests are in place >>for the functionality it needs of B. Is responsibility of B >>to make sure that the development (snapshot) version is being >>updated on a regular basis (so that A has early visibility to >>changes that will impact it). Even this could be automated >>if need be. >> >>There may be a few projects where the number of dependent >>projects is too many for this to be practical (such as >>JBossAS). IMO, this is more of an indicator that the project >>is not componentized well enough (such that the major >>components are independent projects that JBossAS pulls in). > > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. Download > it for free - -and be entered to win a 42" plasma tv or your very own > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > JBoss-Development mailing list > JBo...@li... > https://lists.sourceforge.net/lists/listinfo/jboss-development > > |